This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
Finding non-redirect articles that have class=redirect on the talk page banner shell
I'd like to find articles under a specific category that have a wikiproject 'class' hard set to 'redirect' in the banner shell, but that are not actually redirects. Is there a tool to do this? I took at look at PetScan but I don't see a suitable combination of filters. Thanks. Praemonitus (talk) 04:33, 27 February 2024 (UTC)
Yeah, redirects are detected automatically these days and any incorrect |class=redirect values are just ignored — Martin (MSGJ · talk) 08:53, 27 February 2024 (UTC)
@PrimeHunter: Okay, the scenario I have in mind is for a 'redirect' article that is correctly set to 'class=redirect'. At some point in the future, an editor converts the redirect into a normal article (which I have done myself). If the talk page banner shell is not suitably updated, it could continue to be perceived incorrectly by the WikiProject(s). In my case the particular category is Category:Astronomy and its various sub-categories, but this scenario could apply to any category maintained by a WikiProject. I don't have a good example of this because finding one would literally involve checking tens of thousands of redirect pages. Praemonitus (talk) 17:50, 27 February 2024 (UTC)
@Praemonitus: It sounds like I guessed correctly. As mentioned, your scenario isn't really a problem since |class=redirect is ignored. You can try for yourself to preview Talk:Astronomy with {{WikiProject Astronomy}} or {{WikiProject Astronomy|class=redirect}}. It gives exactly the same result, both in the categories and WikiProject banner. I don't know any tools which look for |class=redirect in the source text. If there were any article examples of your issue for {{WikiProject Astronomy}} then they should appear in my above search but it only gives category talk pages. PrimeHunter (talk) 18:23, 27 February 2024 (UTC)
Any string manipulators in the house? I'm trying to create a report of articles recently assessed as a stub in a WikiProject. The best advice I've received is to base it on the existing Wikipedia:Version 1.0 Editorial Team/Anarchism articles by quality log report, but I'd like to process this page into just the names of the entries that were marked as stubs, i.e., any line that includes "Quality rating changed from <x>-Class to Stub-Class" or "Quality assessed as Stub-Class" (for new articles). Ideally it would just be a bulleted list of the eligible, wikilinked articles with all the other text ignored/deleted. I believe this is possible with some form of Module:String replace/match on {{#invoke:page|getContent|Wikipedia:Version 1.0 Editorial Team/Anarchism articles by quality log|as=raw}} similar to what is done in Template:WPVG announcements/shell but I'm not sure how to handle it without a regex lookahead. Can someone help, or have any tips? czar23:22, 26 February 2024 (UTC)
Czar, really, when you want to find multiple matches you should use a module and iterate over the matches. That said, you can do it in wikimarkup:
{{For nowiki||<nowiki>{{#invoke:string|match|pattern=[^{{truenewline}}]+Stub%-Class[^{{truenewline}}]+|s={{#invoke:page|getContent|Wikipedia:Version 1.0 Editorial Team/Anarchism articles by quality log|as=raw}}|match={{{1}}} }}</nowiki>|count={{#invoke:String|count|{{#invoke:page|getContent|Wikipedia:Version 1.0 Editorial Team/Anarchism articles by quality log|as=raw}}|[^{{truenewline}}]+Stub%-Class[^{{truenewline}}]+|plain=false}}}}
I've used the pattern [^{{truenewline}}]+Stub%-Class[^{{truenewline}}]+ to match any line containing "Stub-Class" (using {{truenewline}} because I couldn't find a better way to use newlines in sets).
Because there are multiple matches, I've used {{For nowiki}} to iterate over each match.
Then I've just used match on the string with the pattern, passing in the count from {{for nowiki}}
Looking at Template:WPVG announcements/shell, it seems to just use patterns to remove the lines that don't match. I'm fairly sure that would require lookahead, as you say.
Here's an alternative approach, which splits the text into lines, and then only returns lines that match:
{{For nowiki||<nowiki>{{If string|source={{Array|get|{{#invoke:page|getContent|Wikipedia:Version 1.0 Editorial Team/Anarchism articles by quality log|as=raw}}|{{Truenewline}}|{{{1}}}}}|target=Stub-Class|plain=true}}</nowiki>|count={{Array|count|{{#invoke:page|getContent|Wikipedia:Version 1.0 Editorial Team/Anarchism articles by quality log|as=raw}}|{{truenewline}}}}}}
If there's a better way to get the intended result with using a module and iterating over the matches, open to that as well but I have yet to venture into Lua-land. Would that version be able to exclude stubs that have been reassessed as another class? Right now Ōsugi Sakae in the above example was formerly a stub but is no longer. czar21:37, 27 February 2024 (UTC)
Czar, you don't need a module for that, just a slightly more complicated pattern. I'm a tad busy right now, but I'll have a shot at it later today. — Qwerfjkltalk07:13, 28 February 2024 (UTC)
Czar, this should work. It checks if the last bolded thing is Stub-Class.
{{For nowiki||<nowiki>{{If string|source={{Array|get|{{#invoke:page|getContent|Wikipedia:Version 1.0 Editorial Team/Anarchism articles by quality log|as=raw}}|{{Truenewline}}|{{{1}}}}}|target=[^{{truenewline}}']+'''Stub%-Class'''[^{{truenewline}}']+$|plain=false}}</nowiki>|count={{Array|count|{{#invoke:page|getContent|Wikipedia:Version 1.0 Editorial Team/Anarchism articles by quality log|as=raw}}|{{truenewline}}}}}}
In the article Good conduct time, does anyone else see the thumbnail for Barber v. Thomas in this article as the transgender flag? Not sure how it relates to that case at all. Seems to be some sort of incorrect thumbnail selection?
Edit 1: this appears to affect multiple court cases per some off-site discussion.
There was some template vandalism on 23 Feb, which included a template transcluded on these pages. Assuming there's been none since, it will probably flush through the system one day. With some combination of null edits, purges and refreshes the process can be sped up, as I think I've just done here. -- zzuuzz(talk)08:03, 29 February 2024 (UTC)
Lol I learned how to read page histories a few tens of thousands of edits ago; I'm asking about querying within a template's code. Sdkbtalk22:45, 28 February 2024 (UTC)
Did the latest software release introduce a change that could be affecting Module:Anchor? There are some issues appearing over at WP:ARC where the <> symbols are used in section headers, such as in this revision. Those characters have been regularly used in section headers at the arb pages for a long time, so I'm wondering if this is a regression. GorillaWarfare (she/her • talk) 20:58, 29 February 2024 (UTC)
Foo>
It's a general MediaWiki issue at phab:T358810, not a local module. It also happens here for the above section header === Foo> === which at the time of writing renders as: " data-mw-fallback-anchor="Foo.3E" data-mw-thread-id="h-Foo>-Anchor_issue_with_LT/GT_symbols-20240229220000">Foo>
It doesn't help to encode it as === Foo> ===. PrimeHunter (talk) 22:05, 29 February 2024 (UTC)
I have never commented here so apologies if I'm in the wrong place, but whenever I go into the text editor on my phone (even as I write this) the text is displayed in white with a dark background as opposed to the previous norm (white background and black text); this also only applies to the editor as the rest of the site (including area around the editor) is like usual. I do not have dark mode turned on for my account (since I prefer it on Wikipedia) but do have it turned on for my phone's system (since I think it looks better). Is there a way I can do something to change my text editor back to how it was? Link20XX (talk) 21:00, 29 February 2024 (UTC)
Page Information says 9 views in the last 30 days. Monthly page views show a very odd pattern. It's been FA of the day on the main page, but only in 2020. Could it be some sort of meme? Searching mainly shows articles from 2017, so it's not in the news. Certes (talk) 17:18, 28 February 2024 (UTC)
This is probably the all-too-common pageviews anomaly scenario, where bot-generated traffic appears human and is recorded as such.
Some site somewhere may be using it as an example of something – Indeed, we see this a lot. I believe Cleopatra is an example. I don't recall what site or app is using it, but that is why it continually remains in the top 10 most viewed pages across all of Wikipedia, and why we excluded it from the 2023 topviews report.
Page Information says 9 views in the last 30 days – that's the talk page. The subject page shows the correct pageviews count. The minor discrepancy with Pageviews Analysis is due to doing 30 days inclusive versus not, which I will fix at some point. — MusikAnimaltalk22:02, 28 February 2024 (UTC)
Global Login can be confusing from a site perspective
Overview
Global login leads to duplicate accounts for users who edit different sites like wikipedia or wikivoyage. I think we can improve this experience with better duplicate account prevention when creating accounts on sites.
In my case, i had a 6 year old wikipedia login, and later created a wikivoyage login. (my password manager only detects existing logins based on the login screen domain, which varies for wikimedia sites). Using the Wikivoyage login on WP did not warn me of account duplication.
We could add an interstitial during site-level account creation to check for a global account first. Also added branding on each site to inform users of network branding and how the login works across all Wikipedia sites.
@Tonymetz: "we" (the editors of the English Wikipedia) can't really do anything about this. However, you may file a feature request at phabricator and then advertise your task to gain support for your idea. — xaosfluxTalk00:02, 1 March 2024 (UTC)
@Tonymetz: Huh? That's exactly how global accounts work. Each username belongs to a single Wikimedia user. Your global account information shows exactly what I would expect (i.e. both English Wikipedia and English Wikivoyage edits). If you wanted a completely different username on Wikivoyage (which isn't normally how things work here), you would have to create a separate (global) account. Graham87 (talk) 08:25, 1 March 2024 (UTC)
try to see it from a new user’s perspective who doesn’t know “global accounts”. They are just editing Wikipedia , wikivoyage etc from various devices. Tonymetz💬16:04, 1 March 2024 (UTC)
@Tonymetz: If you have created a username at Wikipedia then you cannot create the same username at Wikivoyage but have to log in to the existing account to use that name. I guess you refer to a scenario where somebody creates another username at Wikivoyage without knowing that their Wikipedia account also works there. Do you want Special:CreateAccount at Wikimedia projects to list other Wikimedia projects and say that if you already have an account at one of them then you can use it without creating a new account? PrimeHunter (talk) 15:57, 1 March 2024 (UTC)
Yep that would help. Presently, there’s nothing on Wikivoyage that indicates their Wikipedia account works there.
Test out the login experience in incognito/private mode across multiple browsers and you will see what i mean. Tonymetz💬16:11, 1 March 2024 (UTC)
Today, on mobile Wikipedia I saw an option to "download QR code", apparently it is available on every page (including user-pages). I haven't downloaded any, but what is the purpose of them? If it is just some sort of link, then is it really worth it? One can get the option to download it from the three dot menu. —usernamekiran (talk)18:58, 1 March 2024 (UTC)
Hello, I would like to complain about the language link box in the Wikipedia user interface in our new theme. When I click on it, I get a list of languages, but often just as I am pressing the language I want, the the languages jump down a line so that I inadvertently press the wrong language. Annoying. This leads me to the article in a language I don't understand. The reason for this is the "Missing in xxx and more" line that pops up in a delayed fashion at top. Presumably this line pops up because I am translator at Wikipedia, or has multiple languages listed at Wikidata. It also seems I sometimes get listed a language in the top simply because I have visited a Wikipedia page in that language. I don't know. But this feature/bug has been an annoyance for around a year now, and I'm surprised it hasn't been fixed yet (maybe no one has reported it?). I can't be the only one fed up about this. Proposal for solution: Make the place for this suggestion line at the top load from the beginning, so that the lines below don't move when it finally has loaded all the info. Sauer202 (talk) 17:41, 1 March 2024 (UTC)
Thanks for the link. Are you suggesting that I open a similar discussion at mw:Talk:Content translation? I do not want to disable the feature, as I use it a lot. But I do want it to not function in such a crikey "pop-up-like" manner like it does now, it drives me insane. Bad user design, to say the least. It says "279,039 users are trying this feature." Sauer202 (talk) 19:59, 1 March 2024 (UTC)
@Sauer202: The tool is used at many wikis. Discuss it at mw:Talk:Content translation if you want developers of the tool to hear it. The page says "Please provide feedback about the Content translation tool on this page." You can hide the "Missing in" line for yourself with this in your CSS, or meta:Special:MyPage/global.css to hide it at all wikis:
This way, users could customize what the button looks like more. I could try and hack the code to do this myself, but I'm just asking if there's a good reason that this hasn't been done yet. Aaron Liu (talk) 23:07, 1 March 2024 (UTC)
turn of the gadgets manually, add all this to your commons script files, then test it - in each skin - if nothing breaks feel free to open an edit request. — xaosfluxTalk22:26, 2 March 2024 (UTC)
I have a script that adds a subtitle using mw.util.addSubtitle(). I am currently trying to update it so that on the press of a button, it can change its own contents. Here are the approaches I've thought of:
addSubtitle() a jQuery object (which is a variable I'll declare beforehand) and use jQuery methods to update the contents.
This doesn't work because addSubtitle() does not accept jQuery objects for whatever reason, nor does it return some sort of object that can be used to modify the existing subtitle we've added.
Query the page for the ID of the subtitle I've added and change that.
This'd probably work, but when I implement it using jQuery, WMF's ESLint config warms me to "Avoid queries which search the entire DOM. Keep DOM nodes in memory where possible." Weirdly, a vanilla JS implementation doesn't give me any warnings.
Are there better ways that are eluding me, or should I just run with the second approach as my script doesn't constantly update? Aaron Liu (talk) 22:32, 2 March 2024 (UTC)
Well, I don't think that'd work, as the button to update the subtitle is somewhere inside the subtitle (which is mostly untagged text) and I want it to update the entire subtitle instead of just the button Aaron Liu (talk) 23:04, 2 March 2024 (UTC)
Then wrap the text in an element and keep a reference to it.
As I've said when discussing my approach #1, addSubtitle() does not accept jQuery objects: "Argument 1 does not implement interface Node.". Aaron Liu (talk) 23:31, 2 March 2024 (UTC)
Notice [0]. A jQuery object is just a container for a DOM element (or any object(s) for that matter, like an array), and you can access whatever it contains via bracket notation or .get(). Nardog (talk) 23:35, 2 March 2024 (UTC)
Interesting, thanks. I did a bit more testing and just adding [0] right before the rpar seems promising for my approach #1. Thanks again! Aaron Liu (talk) 23:43, 2 March 2024 (UTC)
Switching between mobile and desktop loses the section/anchor part of the URL
I don't know the real name of it. I am referring to the part of the URL that starts with the # and links jumps to a section of that name on a page. This part of the URL is getting lost when switching between desktop and mobile view, and vice-versa.
I don't know if this has previously worked. The behavior is the same desktop to mobile or from mobile to desktop.
It seems weird for it to be intentional. Why not keep the section/anchor part of the URL so that you end up in the same place on the same page? Otherwise you end up at the top of the page and then have to hunt for the section you want. Fine for small pages. For long pages with lots of sections such as the Teahouse or AN/I, its not great.
The anchor is only known to the browser, not the server. Therefore in plain HTML you cannot preserve it. It requires Javascript to read out the anchor and add it to the link, but this too might be problematic, as you might have scrolled away significantly from that point in the page, so the value of such a javascript correction is pretty limited and might be more confusing even than the current behaviour of simply forgetting the anchor. It has always been like this. —TheDJ (talk • contribs) 08:28, 1 March 2024 (UTC)
The redirect was correct before Qwerfjkl changed it. It's the link on the toolforge page itself that needs to be updated. --Ahecht (TALK PAGE) 01:32, 28 February 2024 (UTC)
@Ahecht: Could you answer my question immediately above? This page still links to the "obsolete" page. Is there anyone who has the authority to correct it? I would rather do things the right way the first time, and it would be nice if new users who follow me don't end up being just as confused by being led to "obsolete" documentation. --David Tornheim (talk) 22:33, 1 March 2024 (UTC)
Hello all, I have been experiencing a strange bug as of recently, where sometimes, seemingly completely random as of now, the Wikipedia site only allows me to delete or add 1 single character at a time when editing, and if I try to add or delete more, the site seemingly crashes and reloads automatically, undoing my edits and thus erasing any progress I made. Same thing also can happen when editing my own user page. Very, very frustrating. Any tips would be greatly appreciated. I am using a mobile Android phone. I was told to post here after posting this same request on the help desk. LoneWolf803 (talk) 20:14, 22 February 2024 (UTC)
Judging from the tags, I assume you're talking about the mobile web site (en.m.wikipedia.org), not the app, correct? What version of what browser are you using? What keyboard app (e.g. Gboard) are you using to add and delete characters?
Thanks for your reply, correct, I am using the website not the app. I’m using the latest version (121.0.6167.178) (as far as I know, I’m 99% sure but I’ll double check and update this reply if otherwise) of Google Chrome. I tried using Firefox as well and had the exact same issue. And yes I am using the latest version of Gboard (again I’ll double check but I’m almost positive I updated to the latest). Never had an issue with Gboard before either. I also tried clearing cache to no avail. It happens seemingly randomly like I said. Sometimes it’s when I just start editing a page (for the first time even), sometimes when I’ve had it open for a while. Seems to be no pattern to speak of from what I’ve seen. Should I try deleting and re downloading my browser apps? Thanks again. LoneWolf803 (talk) 00:54, 23 February 2024 (UTC)
If it's only happening on Wikipedia, I doubt reinstalling the apps would help you. With no one else corroborating it's difficult to pin down what's happening, but you can report it on Phabricator.
What do you mean, by the way, to try to add or delete more [than one character at a time]? AFAIK you can't add or delete more than one character at a time with mobile keyboards, unless you're pasting something from the clipboard or you've selected a string. Exactly what action causes the page to reload? Nardog (talk) 23:25, 24 February 2024 (UTC)
Sorry, I didn’t get the notification for this reply until today for some reason. And what I mean by being only able to add or delete one character at a time (I should’ve been more clear about this) is that I can only add or delete one character at a time and then have to publish the edit or else it will crash and automatically reload the page. It just happened again. LoneWolf803 (talk) 06:50, 28 February 2024 (UTC)
@LoneWolf803 bug or not, please don't power through such a problem, it makes (as you've pointed out) dozens of edits - a quick ctrl+f search of your last 500 contributions shows that 292 were +1 or -1 length changes, if all of those were for this reason then that's way too many edits.
I am sorry. Yes of course all my +1 and -1 edits are due to this infuriating bug. I can’t help it. I am doing my best to get this bug resolved and was trying to demonstrate here what it is to try and attain a fix for it faster. Going forward, I will not make anymore edits if the bug occurs (like right now of course it is not) and will just have to wait it out I suppose. As I said, when I have time I will post on the other help page that was suggested. Thanks. LoneWolf803 (talk) 08:42, 28 February 2024 (UTC)
Bug? A number of people have reported issues of a similar nature with GBoard, with different applications. Possibly misbehaved app interactions? Sometimes phones just need rebuilds (like mine does now, it just locks and restarts around twice a day). Are you using WiFi or a cell site (direct)? Perhaps, if WiFi try a different device and try to replicate and remove your network as a possible issue? Neils51 (talk) 23:58, 3 March 2024 (UTC)
Use API to mark watchlist item as read
Is there a way I can use JavaScript to mark a specific watchlist item as read? I've tried inspecting the event triggers of the mark-as-read button, but it references another function and I can't find which script file it comes from Aaron Liu (talk) 13:15, 29 February 2024 (UTC)
You can use action=setnotificationtimestamp. This updates the underlying wl_notificationtimestamp column of the watchlist table. Omitting the timestamp parameters will cause the field to be set to NULL, resetting the notification status. If you are only specifying one page and don't want to mark any revisions newer than a specific one as read, you can use the newerthanrevid parameter, and MediaWiki will determine which timestamp should be used. PleaseStand (talk) 15:37, 29 February 2024 (UTC)
No, rev_id and log_id are different auto-incrementing sequences. For example, log_id=160348009 is a log entry for the creation of a category talk page today, while rev_id=160348009 is the first revision of a user talk page from 2007. The simplest option would be to just leave it out and only specify the page title, so the column is set to NULL. The drawback is that all existing recentchanges records for the title would be considered to be "seen", even ones that were for revisions or logged actions that happened in the meantime. If that's not good enough, use the timestamp parameter, but try to make sure that the timestamp is greater than (not equal to) that of the seen log entry, and that you aren't unintentionally setting it backward (especially because this could cause false "updated since your last visit" markers to appear on history pages). PleaseStand (talk) 23:20, 2 March 2024 (UTC)
Omitting doesn't seem to entirely work. I tried api.postWithToken('csrf',{action:'setnotificationtimestamp',newerthanrevid:1211281013}).done((data)=>console.log(data));, and afterwards the item still had a filled blue circle in my watchlist and visiting the history page still marks things "updated since your last visit". Aaron Liu (talk) 01:45, 4 March 2024 (UTC)
What Cookies are Used to Maintain Login
I have an extension that I use that allows me to automatically delete cookies from a webpage a few minutes after I close it. I would like to whitelist the cookies that Wikipedia uses to remember that I am logged in, so I don't need to log in each time I visit the site, but Help:Logging_in does not list which cookies are used to remember login.
Its not just one or two I need to allow, but a whole set of them. Seems a bit odd, but thanks. That should do it. Cmdrraimus (talk) 03:13, 4 March 2024 (UTC)
Outdent mobile vs desktop
{{Outdent}} appears to line up correctly in desktop view, but is misaligned in mobile view.
This line is indented by beginning with 12 colons.
This line begins with :{{outdent|11}}, so it is indented one stop and preceded by a lines to show the change in indent from 12 to 1.
The lines match up correctly in desktop view, with the upward line corresponding to 12 indents and the downward line corresponding to 1 indent. However, in mobile view, the upward line is indented too far. YBG (talk) 18:18, 2 March 2024 (UTC)
it's because people keep making assumptions that what works in one skin, also works in other skins. I wouldn't use outdent at all honestly. —TheDJ (talk • contribs) 11:54, 3 March 2024 (UTC)
By people keep making assumptions, are you talking about template developers or template users? Or something else?
You say that you wouldn’t use {{outdent}} at all. I’m interested to know what you would do when a threaded discussion gets 12 levels deep? Would you Outdent without using the template? Or would you continue indenting more and more?
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
The Special:Book page (as well as the associated "Create a book" functionality) provided by the old Collection extension has been removed from all Wikisource wikis, as it was broken. This does not affect the ability to download normal books, which is provided by the Wikisource extension. [3]
Maintenance on etherpad is completed. If you encounter any issues, please indicate in this ticket.
Gadgets allow interface admins to create custom features with CSS and JavaScript. The Gadget and Gadget_definition namespaces and gadgets-definition-edit user right were reserved for an experiment in 2015, but were never used. These were visible on Special:Search and Special:ListGroupRights. The unused namespaces and user rights are now removed. No pages are moved, and no changes need to be made. [4]
A usability improvement to the "Add a citation" in Wikipedia workflow has been made, the insert button was moved to the popup header. [5]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 5 March. It will be on non-Wikipedia wikis and some Wikipedias from 6 March. It will be on all wikis from 7 March (calendar). [6][7]
Future changes
All wikis will be read-only for a few minutes on March 20. This is planned at 14:00 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [8]
The HTML markup of headings and section edit links will be changed later this year to improve accessibility. See Heading HTML changes for details. The new markup will be the same as in the new Parsoid wikitext parser. You can test your gadget or stylesheet with the new markup if you add ?useparsoid=1 to your URL (more info) or turn on Parsoid read views in your user options (more info).
I've noticed in recent weeks that <blockquote> elements have gained additional indentation, which is a terrible waste of space:
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
{{quote}} doesn't have this issue, even though it uses <blockquote> internally:
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Your screenshot shows they're not identical; the first has larger vertical margins. And Hairy Dude specifically said it's about the mobile interface. Nardog (talk) 11:53, 3 March 2024 (UTC)
I tried to fiddle with {{Blockquote/styles.css}} to make the two renderings match, but it looks like I am doomed to never understand how CSS works. In any event, the OP wants less vertical space, not more, so that wouldn't really be a good fix. The MediaWiki developers have been messing with vertical space between elements recently, which might have something to do with this discrepancy. See T358921 and its predecessors. It appears that every time they change something, there are undesirable side effects. Their suite of test cases is probably not extensive enough. – Jonesey95 (talk) 16:19, 3 March 2024 (UTC)
I'm seeing excess vertical space around the tag version in Vector 2022. Using the Inspector verifies that <blockquote>...</blockquote> uses .mw-body blockquote, applying padding: 8px 32px; in the tag-only section, while the template applies padding: 0 32px; to .mw-parser-output .templatequote to the same tag. – Jonesey95 (talk) 18:50, 3 March 2024 (UTC)
Random slideshow images are not allowed in articles, I think. There is probably a guideline somewhere. If you want to show multiple images in a small space, <gallery>...</gallery> tags are useful. See Help:Gallery tag for more information. – Jonesey95 (talk) 21:22, 5 March 2024 (UTC)
As initially discussed here (and at phab) the ability for bot edits to trigger watchlist notifications via email has been disabled. The only suggestion provided (i.e. "we're not going to undo this") has been to create a toolforge tool to trigger these notifications. I do not have the knowledge or expertise to do so, hence a request for someone to do so, with (as suggested) the ability for users to input their watchlist key to trigger the tool. (please do notping on reply) Primefac (talk) 12:11, 4 March 2024 (UTC)
And for what it's worth, I get why this was done, my parentheticals are more cheeky commentary than anything truly negative. Primefac (talk) 12:20, 4 March 2024 (UTC)
Just checking - your ask involves: (a) giving someone else your private watchlist token, and likely also your email address (b) have them watch your watchlist for you (c) have them send you emails about your watchlist changes? (And have them do this via a program that they will write, maintain, and operate - possibly with some screening/flood parameters)? — xaosfluxTalk10:38, 5 March 2024 (UTC)
Unfortunately, yes. There are some commercial services that do that - so the benefit would be that it could be ready to go and likely has ongoing support. — xaosfluxTalk14:05, 5 March 2024 (UTC)
Yes, that is exactly what was suggested. In the meantime, I suggested creating a tool in toolforge to do the work for you, you could potentially create a generalized one that users could "sign up" by providing their watchlist token. So one person would need to create and maintain the tool and others could just use it (and don't need to re-invent the wheel).Please don't insinuate that I am being unreasonable when I am simply asking for what I was told to ask for.Primefac (talk) 12:33, 5 March 2024 (UTC)
I don't think you have an unreasonable ask, just trying to outline all of the components for anyone that wants to take this up. For example, filtering parameters may be useful if you still want to use on-wiki email relay for non-bot flagged items. — xaosfluxTalk14:07, 5 March 2024 (UTC)
As an short-term solution, you could use the PageProbe extension in Firefox, or try to find something similar. The main problem with it is that it can not deal with an full watchlist, if something goes off your watchlist while you have not taken a look it is gone. It can check the watchlist however often you want (do not go under 10 seconds). You right click the first item in your watchlist, select "track content" and edit the tracker to your liking. It takes some time to get right, but works on it's own when you are satisfied with it. It will show up with it's icon and the number 1 when your watchlist has updated. The extension will only check your watchlist while your browser window is open and your computer on. Once your watchlist is updated open both the extension to clear the counter and your watchlist. Snævar (talk) 22:06, 5 March 2024 (UTC)
RefRenamer is a great/fun tool (though I wonder how much churn it will create as users continue to re rename based on personal preference). To your point, the example Diff has only a single instance. Generally it's a good idea not to use ref names when there is no reason. Wait for future editors if they need it (in most cases they never will). One might say you are being prepared, but really it clutters the article, adds complexity, and is one more thing to deal with (name conflicts etc). In fact, RefRenamer even defaults to removing ref names that are singular. There might be a rule or guideline somewhere. As for VE, I don't know, maybe it's built-in to not add ref names for single refs. -- GreenC16:01, 5 March 2024 (UTC)
VE developers didn't spend any time on this issue at development. The only rationale I can ascertain was the general "source editing will be a thing of the past so we don't have to care about certain qualities", well-named references being one of those qualities. There was a community wishlist item on the point that scored highly that went nowhere. Izno (talk) 16:35, 5 March 2024 (UTC)
@RoySmith: Agree with Nardog; if it doesn't have one, it doesn't need one. That said, nobody is stopping you from optionally adding refnames directly to the citations. Also, iirc RefRenamer does permit you to add a name to a ref that is unnamed; it isn't the default option, but it allows you to add unnamed refs to the activity table from the list of other refs in the article, and from there you can supply a name. At least, that's what I recall. Mathglot (talk) 01:34, 6 March 2024 (UTC)
It does allow you to optionally rename refs whose names were not autogenerated, but it currently doesn't support adding names to refs that aren't named at all. Nardog (talk) 01:37, 6 March 2024 (UTC)
Speech synthesizer access to Wikipedia articles for the visually impaired
Most visually impaired people that need it will already have screen reader software available on their device. I don't see any advantage to doing it server-side. --Ahecht (TALK PAGE) 18:18, 5 March 2024 (UTC)
The closest thing we have to that is Phonos, but it can not deal with anything close to an full article. See mw:Help:Extension:Phonos for instructions. See also c:Category:Spoken Wikipedia - English for audio files of old versions of English Wikipedia articles. I do agree tho that an voice box for an full article on Wikipedia itself is not necessary. Snævar (talk) 22:21, 5 March 2024 (UTC)
Thanks, I would never have thought of that change at Gangadi (Q110251921). I might look at patching the module later but it uglifies the code when trying to handle all of Wikidata's quirks. Johnuniq (talk) 05:27, 6 March 2024 (UTC)
It's something that's caught me out before! Lua throws a wobbly if you try to access a.b.c unless you first check that a.b exists, and before that to check that a exists. I'll take a look later — Martin (MSGJ · talk) 08:39, 6 March 2024 (UTC)
Should be fixed now. Just a bit surprised that (a) this issue has never occurred before and (b) RexxS made this mistake at all! — Martin (MSGJ · talk) 10:22, 6 March 2024 (UTC)
Weird issue where Vector 2022 is being forced on a single page.
So I use desktop Vector 2010 on mobile, and have a global preference set to enforce it. But when I go to Wikipedia:Sockpuppet investigations/PaullyMatthews (I was checking back on a report I made) I get Vector 2022 forced.
I also saw that, and also on some other SPI pages. I'll bet it was a WP:THURSDAY feature. I've refreshed and purged a few times and it seems to have now gone (for me anyway). -- zzuuzz(talk)22:50, 22 February 2024 (UTC)
Force-refreshing the SPI page has fixed it for me. This wasn't the first time; I recall some other time that an editor at VPT found Vector22 being forced and the link to it caused me to see it as well. SWinxy (talk) 04:53, 23 February 2024 (UTC)
I've purged and refreshed the page, still the same problem. I'm using the desktop site on mobile, so the hardest refresh isn't an option (and why Vector 2022 is so very thoroughly broken for my purposes). -- LCU ActivelyDisinterested«@» °∆t°02:25, 23 February 2024 (UTC)
I'm working my way through all the FAC pages listed at WP:FAC. So far, it's pretty repeatable that each /archive1 page I open up, it opens in V22. Doesn't seem to matter if it's a FAC I've ever looked at or not. Some unreproducible number of page reloads eventually gets me to the non-V22 version. RoySmith(talk)02:57, 23 February 2024 (UTC)
Can confirm I'm having this problem on certain random pages, all under the Wikipedia namespace (mostly AFDs and SPIs), and it usually goes away when I refresh. I also have Vector 2010 as default. LilianaUwU(talk / contributions)02:44, 25 February 2024 (UTC)
Late, but I have also been getting this once every few weeks for the last year or so -- one page (sometimes an article, sometimes a template, sometimes a userpage) will just randomly become obsessed with being in Vector 22 regardless of my own settings, CSS, et cetera. It is quite disruptive. jp×g🗯️09:36, 7 March 2024 (UTC)
Yeah, but this one doesn't fit the pattern of transcluding Special:Prefixindex (which typically happens on sub-pages to create the back-link header). @GhostInTheMachine is this reproducible for you? RoySmith(talk)15:50, 23 February 2024 (UTC)
Sorry if this has been brought up already but I do a lot of work on AFD daily log pages and they keep shifting skins. The layout can even change when I refresh the page. The view I don't want is a small middle column and two wide columns on either side. I'm used to the old view with a large middle column that has the majority of content and a top menu and only a right-hand side columns. There was a message at the top of a page that mentioned XFD discussion so I uninstalled that feature but it hasn't changed things for me. I have a week of AFD daily logs open in tabs and about 5 pages have the old view and 3 pages have the alternate view. Refreshing the page helped this morning (the view would switch back) but that doesn't work any longer. I've looked at my Preferences but nothing has changed there, still Vector Legacy.
It's strange how the layout of content really affects how I work and I find this new view, with tons of white space, off-putting. Any ideas how I can return things to normal for all AFD daily log pages? Thanks for any suggestions. LizRead!Talk!05:19, 24 February 2024 (UTC)
Well, Wikipedia:Articles for deletion/Log/2024 February 17 was one particular page that just kept showing the alternate, white space skin (I should really learn their names). I did find I could hide the right-hand side menu which helped. But I just refreshed this page and got the old style came back so who knows? But this time, I was running into this phenomena on AFD daily log pages (as mentioned in the message below this one). I should have known it was a system bug, not just me, so thanks for moving my message to join others that mention similar problems. LizRead!Talk!20:07, 24 February 2024 (UTC)
Technical summary
Where Special:PrefixIndex is typically used
To summarize what's going on in a non-technical way, this appears to be a bug related to Special:PrefixIndex, which is used to generate the back-link header that's seen on subpages. A subpage is basically any page that has a slash in its title in certain namespaces (possibly all spaces except mainspace?). And what I'm calling the "back-link header" is the collection of links that take you back to the parent page. This is commonly seen in process pages such as WP:AfD, WP:SPI and WP:FAC. If you're seeing this on one of those kinds of pages, that explains it. If you're seeing this on a page that's not a subpage, that's a lot more interesting, and please post your exmples here. RoySmith(talk)19:28, 24 February 2024 (UTC)
I use the Vector 2010 theme, but have noticed that on a few AfD pages it switches to some sort of different, worse, minimalist theme. When I click "switch to old look" it takes me to the user page where it shows I am using the old look. Most pages are fine including this one. Is this a bug? SportingFlyerT·C22:32, 24 February 2024 (UTC)
Beginning yesterday, whenever I visit a page starting with the prefix Wikipedia:Featured article candidates/, the page is displayed in Vector 2022 (I think?). Every other page, and those pages in edit mode, display in the skin I have set, which is not that. Anyone know what is causing that? Nikkimaria (talk) 02:33, 26 February 2024 (UTC)
I've just been chatting with some of the WMF RelEng folks on IRC. I don't want to speak for them, but I will say that they're aware of the problem and working on it. The best thing for most of us to do at this point is to let them do their thing and watch T336504 for status updates. It looks like doing a hard reload (hold down the shift key while reloading in Chrome; I assume soemthing similar on other browsers) gets you back to your configured skin, so in the meantime, that's a viable workaround. RoySmith(talk)15:35, 26 February 2024 (UTC)
Unfortunately such refresh options are not available on mobile, and even clearing all site data for Wikipedia doesn't clear the issue from all pages. -- LCU ActivelyDisinterested«@» °∆t°22:35, 26 February 2024 (UTC)
While editing the macOS text editing shortcuts section of Table of keyboard shortcuts, I got a table of all available shortcuts by dumping the system default configuration file with plutil(1) (you may notice that I mentioned it to support my edits in the edit summary). I think it's beneficial to cite it in the article, but don't know how. WP:CITE has no mention of configuration files, a quick google search turned up nothing either, so I came here to ask. Hym3242 (talk) 16:02, 7 March 2024 (UTC)
@Hym3242 the most important thing is to reference it, styling is secondary. A quick search for how to cite software came up with this. While using a citation template is handy, it is not required. So just <ref>Put in your source</ref> and you can let someone else worry about that. (They may chime in here with a better idea of course!). Note, no part of this response is a measure of if your source is actually a good type of source or not. — xaosfluxTalk16:50, 7 March 2024 (UTC)
Thank you! I know this may not be the best type of source, but in defense of my choice, macOS has many very useful but undocumented (in the official documentation/support pages/manpages) keyboard shortcuts that I hope to cover, and there are only two main ways to know about them: through Q/A sites / personal blogs, or by basically reverse engineering the software. The first one is obviously not generally acceptable on wikipedia. Hym3242 (talk) 18:17, 7 March 2024 (UTC)
HotArticlesBot stopped running
HotArticlesBot, which builds lists of the most edited articles in each wikiproject, normally runs at 2:45am ET every night but last night did not run. I reported it to an operator very early this morning, but there hasn't been a response yet. This isn't a very critical bot, but wikiprojects use the results. Stefen Towers among the rest!Gab • Gruntwerk19:00, 6 March 2024 (UTC)
Yes, as a matter of fact, while working on Quarry queries yesterday, I discovered it, and immediately found a use for it, separate from this matter. As for HotArticlesBot, it got restarted last night. But at least now I know I have a potential way to replace it if it goes away. Thanks for the suggestion at any rate! Stefen Towers among the rest!Gab • Gruntwerk22:51, 7 March 2024 (UTC)
LibreOffice now only shows "Fresh" version but not "Still" version
LibreOffice offers two concurrent versions: "Fresh" (hot off the press) and "Still" (stable, proven), however now it shows only "Stable" - this is not an adjective that The Document Foundation uses to describe either of its versions. See:
Currently, LibreOffice offers two concurrent releases:
v24.2.1 If you're a technology enthusiast, early adopter or power user, this version is for you!
v7.6.5 This version is slightly older and does not have the latest features, but it has been tested for longer. For business deployments, we strongly recommend support from certified partners which also offer long-term support versions of LibreOffice.
I posted a comment on the LibreOffice talk page on 2023-10-02, but there has been no response since then. I realize that this issue is connected to Wikidata, maybe Wikidata cannot handle two concurrent versions? Is there a work-around? Enquire (talk) 05:45, 8 March 2024 (UTC)
List of State Of The Union Reports
Despite making over 1000 edits over many months, the wikipedia android app cripples me from creating my home page or any other new page, such as List of State Of The Union Reports, also responding on Talk: pages requires work-arounds. 3MRB1 (talk) 09:31, 8 March 2024 (UTC)
I would support adding talk pages where they don't exist. Especially if you also set it up with archiving set to the default setting of 4 talk sections minimum before archiving. Many editors are hesitant to start a talk page, and even more are hesitant to set up talk archiving. Or completely unable to do so due to lack of knowledge and time. --Timeshifter (talk) 16:53, 5 March 2024 (UTC)
Way back at the dawn of time (ten or eleven years ago, if not a bit more), I believe there was at least an unofficial policy of creating talk pages for all articles for which they did not exist, with one or two WikiProject templates if nothing else. This would get the articles onto the radar of one or two projects interested enough in the subject to take a look and refine what was there. I did a lot then, and so did a handful of other editors (Dr. Blofeld springs to mind, for one). I think it's still a useful task, though I don't know how active many WikiProjects are any more compared to where they used to be. --Ser Amantio di NicolaoChe dicono a Signa?Lo dicono a Signa.17:22, 5 March 2024 (UTC)
My YAGNI comment above notwithstanding, I think @Timeshifter makes an excellent point. We encourage editors to discuss things on the talk pages so we should be working to remove any barriers to that happening. RoySmith(talk)17:23, 5 March 2024 (UTC)
The redlink for the talk page on 1857 Faroese general election takes you to page with a "Start a discussion" button so I assume the page is automatically created when someone does. No real barrier there. Creating talk pages is useful for adding projects and importance ratings and there are people who routinely do this for the Tree of Life project. I suppose the 100,000 articles without talk pages don't have an obvious home in an active project. — Jts1882 | talk17:50, 5 March 2024 (UTC)
When you're a newbie, everything that doesn't work exactly as you expected, or has an extra step, is a barrier to entry. RoySmith(talk)17:59, 5 March 2024 (UTC)
I'd say the page with "Start a discussion" button was easier to understand for a newbie than the talk page where they have to select "edit" or "+". — Jts1882 | talk18:11, 5 March 2024 (UTC)
Jts1882. Before the talk page was started the red link took me directly to an edit window. But it did not have a spot for a talk section heading. So it is confusing. Not as easy as the "add topic" link that takes care of the equal signs for headings.
By the way does anyone here use an iphone? Please help with this template test:
I don't have a problem creating new talk pages. I have been editing many years. I am more concerned with new editors. I just chose that preference. Just to see what it offers. Do you know of a non-existing talk page I can check? If it makes adding a new topic to a non-existing talk page simple, complete with a header line, then maybe that should be the default setting for all users, both logged in and not logged in. --Timeshifter (talk) 13:27, 6 March 2024 (UTC)
Matma Rex. I remember now why I disabled it. It only provides a limited editing toolbar. Something I hate anywhere I see it: Mediawiki.org, Fandom community forums, etc.. If some editor wants to discuss tables or references, they can't do so with the first post on a talk page. The full functionality of the wikitext or Visual Editors are needed for that. It seems like some developers are always trying to sneak in these limited editing windows on all wikis. I sometimes don't use the "Add topic" editing window on talk pages, and here on the Village Pump, for the same reason. I start a new topic with the wikitext editor instead. So I think the full editing toolbar should be in that first post editing window. At least in the source tab. --Timeshifter (talk) 15:24, 6 March 2024 (UTC)
It is just busywork (ie waste of time) creating talk pages with nothing but bannershell or talk page header. Only create them if you are going to add a project, or say something useful. Graeme Bartlett (talk) 00:36, 6 March 2024 (UTC)
There is no need to put anything on the talk page at first. A period will do for starting the talk page. It's not a waste of time if it helps encourage more discussion from newbies. WP:TALK#CREATE should be changed. Apparently, from this discussion, it was common in the past to start talk pages. --Timeshifter (talk) 01:32, 6 March 2024 (UTC)
I think a talk page should automatically be created when an article is started. Along with archiving being set up. It hurts nothing to have it set up. Since it is automatic it doesn't do anything until it is needed. I see so many talk pages with messed-up archiving, or none at all. I also think links to talk section headers should be permanent links that work even when the talk section header name is changed. Without having to set up anchors. --Timeshifter (talk) 03:46, 6 March 2024 (UTC)
"Since it is automatic it doesn't do anything until it is needed" Nope ... the bot has to check whether it needs archiving every day. Each check might not take that long in the grand scheme of things, but it would definitely add up over millions of pages that mostly wouldn't need archiving. Graham87 (talk) 06:26, 6 March 2024 (UTC)
I have seen various discussions about templates, substitution, bots, server load, etc.. And the developers have always said it was not a problem. And I don't see why an archiving bot would have to check every day. If server load ever became a problem (which I doubt), then the bot could be set to check only when the page is edited, and not more than once a day. --Timeshifter (talk) 12:10, 6 March 2024 (UTC)
The problem is that archiving bots are not run by MediaWiki. They are run by individual members of the community, and thus WP:DWAP does not apply. lowercase sigmabot III is run by Σ, who last edited 20 months ago. A feature to check only when the page was edited does not exist, and I doubt someone who last edited over a year ago is interested in setting that up.HouseBlaster (talk · he/him) 04:33, 7 March 2024 (UTC)
Also, I was curious: ClueBot III is currently set to archive 10,617 pages and lowercase sigmabot III is set up on 37,550. Given there are over six million articles, there is no way the bots can handle being set up on all of the pages.HouseBlaster (talk · he/him) 04:37, 7 March 2024 (UTC)
Thanks for Wikipedia:Don't worry about performance link. It says the opposite of what you are saying. It says that if there is a problem sysadmins will fix it. And that they have done it many times already. Regardless of whether the problem was at the system code level, or with templates edited by users. So, "Don't worry about performance". The Brion Vibber quotes are illustrative of the point. He was the chief sysadmin for awhile. And adding archiving to all talk pages would probably require developer help. So stop worrying. Or as Brion Vibber said (upper case letters are his, emphasis is mine): "I made a general recommendation not to go running around saying THE SKY IS FALLING THE SKY IS FALLING about templates BASED ON SUPPOSITION AND PARANOIA." --Timeshifter (talk) 13:48, 7 March 2024 (UTC)
Let me try again: we don't have to worry about performance of MediaWiki (the software that Wikipedia uses). The archiving bots are not part of MediaWiki. And if we were to do this, it would not require developer help. We would need to run a bot to add the code to all talk pages, which is trivial.HouseBlaster (talk · he/him) 17:10, 7 March 2024 (UTC)
Bruh moment. Every single day?! There isn't a way to specify that e.g. talk pages that haven't been edited in xyz days only get checked every week?? jp×g🗯️09:16, 7 March 2024 (UTC)
Maybe not currently. But there is no reason that the template couldn't be changed to check only when the talk page is edited, and not more than once a day. If it needed to be done due to server load, then developers would make sure it happened. According to WP:DWAP. See my reply to HouseBlaster higher up. --Timeshifter (talk) 13:53, 7 March 2024 (UTC)
It is not the template which would need to be changed, it is the bot. The template just tells the bot what to do, if that makes sense. HouseBlaster (talk · he/him) 17:20, 7 March 2024 (UTC)
The template just adds a backlink to the page, visable from WhatLinksHere. It doesn't "call" the bot to edit the page, as it were. — Qwerfjkltalk17:35, 7 March 2024 (UTC)
According to WP:DWAP, however it is done (templates, bots, system code, etc.), the sysadmins can handle any problems with server loads. That's not our problem. They will intervene as necessary to fix problems. So we can add archiving to all talk pages now. --Timeshifter (talk) 18:50, 7 March 2024 (UTC)
Sysadmin intervention would probably consist of just blocking the bot, if it managed to cause problems with the stability of the site. I doubt it would come to that, though; even if it ran all day doing nothing but visiting every talk page, the servers wouldn't feel it. So you don't have to worry about the bot (any bot) taking Wikipedia down, but you do have to worry about the bot doing what it's supposed to, and the real problem you'll have is that it won't be able to process all pages in a day that way. I doubt sysadmins would help with that.
That's assuming it really works as naively as you say; there are many obvious ways to do this better (e.g. checking the API equivalent of Special:RecentChangesLinked, or checking the date of latest edit to the page, which can be done in batches of 500), and I would hope the bots already do something like that. Matma Rextalk19:04, 7 March 2024 (UTC)
That will clutter our watch lists adding archiving to pages that may never need it. Why not just add it to pages over a certain size? Hawkeye7(discuss)19:06, 7 March 2024 (UTC)
I don't see talk pages on my watch list unless the talk page is edited or archived. The default setting for threads being archived is after there are a minimum of 4 threads. And only after the latest post in a thread reaches a certain age. And then only when there is a 5th thread started. Just adding archiving does not cause a lot of talk pages to show up instantly on watch lists. Because it takes awhile to reach those minimum number of threads. Many talk pages never get 4 threads. --Timeshifter (talk) 19:43, 7 March 2024 (UTC)
The default value for minthhreadsleft in Lowercase sigmabot III is actually 5 and that for ClueBot III's equivalent, minkeepthreads, is 0. Here's Lowercase sigmabot III's Python source code and that for ClueBot III in PHP. My Python is only beginner-level and my PHP is virtually nonexistent so I'm not 100% confident about the bots' exact mechanics, but I can't find any fancy API calls in either of the above links. We're getting way off-topic from the start of the thread though. Graham87 (talk) 12:01, 8 March 2024 (UTC)
There's an outdated map at Kolkata Metro#Network map. I wanted to update it, and noticed that data is extracted from Wikidata, but there is no map in there. I tried reading the template documentation but couldn't understand much of it. Can anyone explain in layman's terms, where is the data coming from? And how to I update it? Thanks! —CX Zoom[he/him](let's talk • {C•X})13:22, 7 March 2024 (UTC)
I know Extension:DPL is used somewhat on Wikinews but is quite resource heavy. I wonder how would DPL3 work on Wikipedia? I think there would need to be some optimizations to make it work well, and we would likely have to limit the namespaces that DPL works in. Maybe there is a way to get a less resource heavy and more optimized DPL4 that has all of the features of DPL3 but without the performance problems of it.
Some uses I can see for DPL3 include getting the number of transclusions of a template, listing all of the pages proposed for deletion alongside their reasons, etc. AwesomeAasim20:06, 8 March 2024 (UTC)
Severely shortened watchlist
I have thousands of pages on my watchlist. I have it set to show me the 250 latest items from the last seven days. I know there are that many items to show. But for some reason, without checking any of the "do not show" boxes except my own edits and wikidata, I am only seeing 15 items. If I hide bots, I get a normal-looking watchlist (without the bot edits). If instead I uncheck wikidata, I see more changes, but still nowhere near 250. Anyone know what is causing this and how I can get a full watchlist view that includes the bots? —David Eppstein (talk) 07:34, 9 March 2024 (UTC)
ChristieBot, which maintains WP:GAN, is down, and I don't know what the problem is; I would appreciate any help. It's particularly annoying as there is a backlog drive going on at the moment.
I was prompted by the WMF via phab:T357554 to upgrade to the new toolforge environnment. I made the suggested Python code changes, and ran into some problems when I tried to submit via the toolforge jobs command so I reverted to the code that was running earlier today (and I've checked that the reversion really did happen) and reenabled the cron job. Now when it runs it fails immediately with
ModuleNotFoundError: No module named 'importlib.metadata'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "www/python/src/GANbot.py", line 20, in <module>
import pywikibot
File "/data/project/shared/pywikibot/stable/pywikibot/__init__.py", line 21, in <module>
from pywikibot import config as _config
File "/data/project/shared/pywikibot/stable/pywikibot/config.py", line 60, in <module>
from pywikibot.backports import (
File "/data/project/shared/pywikibot/stable/pywikibot/backports.py", line 206, in <module>
import importlib_metadata
ModuleNotFoundError: No module named 'importlib_metadata'
Why is it now complaining about importlib.metadata? I tried exiting the tool and going back in via "become ganfilter" in case something from the toolforge job submit had changed the working environment but that didn't make any difference. Any help appreciated. Mike Christie (talk - contribs - library) 20:47, 8 March 2024 (UTC)
I have now managed to resolve at least one of the problems with the new toolforge version and it is giving me the same error about importlib.metadata on that version as well, so I seem to have the same problem both ways. Mike Christie (talk - contribs - library) 20:56, 8 March 2024 (UTC)
I've just realized that the bot stopped running just a few hours before I began working on it; I hadn't noticed it wasn't running. That means the problem is not related to the change to toolforge. Per a suggestion on phab I removed the PYTHONPATH environment variable but it is now complaining that it can't find pywikibot. I currently have PYWIKIBOT_DIR set to the .pywikibot directory in my tool's environment. If memory serves that's created at the time I built the tool. I tried removing the PYWIKIBOT_DIR but that didn't help, so I'd be grateful for any pointers to anything else I can try. Mike Christie (talk - contribs - library) 22:22, 8 March 2024 (UTC)
This looks to be partially because you're using the shared pywikibot installation which I wouldn't recommend as it can be changed without you knowing about it. It's also present at different locations depending on whether you use the Grid or Kubernetes. Feel free to add me as a maintainer – I can help sort it out. – SD0001 (talk) 10:03, 9 March 2024 (UTC)
@Mike Christie I have created a fresh venv using the python3.11 image. Inside a webservice shell with the venv activated, I ran pip install pywikibot pymysql python-dateutil. Please create a requirements.txt with the list of dependencies and versions so that this would be smoother in the future. The user-config.py file was incompatible with the latest version of pywikibot (9.0.0) so I've moved that to user-config-old.py and created a basic new config file.I validated a one-time run by running:
The first two commands here should always be run before installing dependencies or running any python code, as the python version on the bastion is different from the one on k8s.To automate it as a cron job, toolforge jobs run christiebot --command 'www/python/venv/bin/python www/python/src/GANbot.py' --schedule '0,20,40 * * * *' --image python3.11 should work, though I have not tested it. Once you confirm this works, set it up in a jobs.yml file so that in the future if any changes are required, you can just tweak the file and do toolforge jobs load jobs.yml. – SD0001 (talk) 12:16, 9 March 2024 (UTC)
SD0001 -- the job ran fine -- thank you. I tried running the same three commands that you ran, just to check that I understood what was going on, but source www/python/venv/activate fails with "No such file or directory". Is there something I'm missing? Re the requirements.txt, the packages the application imports are: urllib.parse re datetime pywikibot pymysql operator sys time dateutil.parser os configparser. I have put these in a requirements.txt in www/python/src though I would assume some of these are natively installed and don't need to be there; let me know which and I can remove them if necessary. Also, I've changed GANbot.py back to the toolforge code, which means configparser is probably not needed; I left it there in case I have more trouble getting the toolforge code to work. Mike Christie (talk - contribs - library) 14:22, 9 March 2024 (UTC)
@Mike Christiesource www/python/venv/activate failure must be because you were not in the home directory. Sorry, I should have mentioned source ~/www/python/venv/activate so that it works from anywhere (once you have done become ganfilter, of course). It should be source ~/www/python/venv/bin/activate, edited above. – SD0001 (talk) 15:40, 9 March 2024 (UTC)
And python-dateutil. The versions should also be included (in pywikibot==9.0.0 format). The live versions can be via pip list. – SD0001 (talk) 16:39, 9 March 2024 (UTC)
The scheduled job is working too. Thank you for all the help. I will create the yaml file and work on a few other cleanup issues such as possibly using the toolforge env vars rather than the config but this is now resolved. Mike Christie (talk - contribs - library) 17:30, 9 March 2024 (UTC)
Some Wikipedia articles are being attached to separate and distinct Wikipedia articles. This appears to be to increase viewership from search engines. For example, an article about X is attached to an article about Y. The article becomes X,Y and clearly draws search engine results to X. Who do I report this. It is very complicated.
Please provide an example of exactly what you are seeing; what you expect to see; and why you think there is a technical problem. — xaosfluxTalk23:23, 9 March 2024 (UTC)
I just did. To me, at this point, I should contact technical support because publicly giving examples could cause me to be harassed. Starlighsky (talk) 23:29, 9 March 2024 (UTC)
Can you explain what "attached" means here? Is someone copying and pasting text from article X onto the end of article Y? Is it a comment about titles, that we have articles on Paris, on Texas and also on Paris, Texas? Does "attached" mean "wikilinked", and you feel that a certain article should not link to a certain other article? An example would really help us to understand what problem you may have found. Certes (talk) 23:45, 9 March 2024 (UTC)
All I know is that they take two thing unrelated. For example, it would be an article about sea turtles which is attached to an article about a specific car dealership. So it ends up being "Wikipedia: Specific car dealership.Sea Turtles".
It appears to be a way to increase search engine results for the car dealership. The mechanisms get more complicated, but that is the basic idea. I really need to contact technical support. Starlighsky (talk) 00:00, 10 March 2024 (UTC)
Is this a problem with some particular search engine (such as Google, Bing, DuckDuckGo, etc.) returning "Wikipedia: Specific car dealership.Sea Turtles" when you type in some search term? If so then the problem may not lie within Wikipedia. Six articles mention both car dealerships and sea turtles, but they seem to be legitimate entries without undue weight. For example West Edmonton Mall contains both a dealership and an aquarium. Unless you provide an actual example stating clearly where you are looking (e.g. reading Apple), what you see, what you expected to see and what is wrong, we are unlikely to be able to help you further. Certes (talk) 00:24, 10 March 2024 (UTC)
I think this is some kind of sleazy SEO thing that the operators of those websites are doing. I don't know if we can really do anything about it (although I do note that they're just serving the Wikipedia logo with that page, which is trademarked, so maybe that has legs?) jp×g🗯️04:48, 10 March 2024 (UTC)
The article you linked is at https://wiki.alquds.edu – which is not Wikipedia, just a mirror of it, so there is nothing anyone here can do about what happens there. Mirror sites which copy some articles from Wikipedia, or even all articles from Wikipedia, are permitted as long as they comply with the wmf:Terms of use. But no one here can dictate what they do on their own website, unless they are violating the Terms. Mathglot (talk) 05:06, 10 March 2024 (UTC)
Yes, Al Quds is simply taking Wikipedia's content, which does not have the problem described here, and adding advertising. As Wikipedia is not adding the problematic text, and does not control or endorse Al Quds, the complainant's only recourse is to contact Al Quds and ask them to change their mirror. Certes (talk) 10:13, 10 March 2024 (UTC)
The user-generated content can be freely copied and redistributed in compliance with CC-BY-SA/GFDL, but using the Wikipedia name and logo is a trademark infringement. Nardog (talk) 10:26, 10 March 2024 (UTC)
Thanks to everyone for your help and insight. I just wanted to point it out to Wikipedia. I personally don't have problems with it, though. It seems the university appreciates U.S. cultural topics like Broadway shows and so on. I did want to report it in case it was something more serious. Starlighsky (talk) 13:34, 10 March 2024 (UTC)
AI helper
Hello! Has there ever been talked about developing an AI helper for article editing/creating? I was tutoring in a wiki-activity today and one of the participants asked if there was such a thing. We were dealing with EnWiki and SqWiki (my homewiki) and even though we mentioned the possibility of help venues such as the Teahouse (or its equivalent in SqWiki) they explained that they were hoping for real-time artificial tutoring that could overseer their progress and fix any/most arising technical problems. I'm pretty sure in the age we live in that plan is not too farfetched so I was wondering if there has been any concrete work in this direction. - Klein Muçi (talk) 13:53, 6 March 2024 (UTC)
So I asked chatgpt what it thought about using AI to "create or edit articles" on Wikipedia. While it agreed that it had some benefits, it also mentioned the following concerns:
* The possibility of creating biased content.
* The likelihood that the results might re inaccurate or incoherent.
* Possible perception of AI undermining the "collaborative and volunteer-driven" aspects of Wikipedia.
* Risks associated with violation of copyright and responsibility for content.
Fabrickator, hello and thank you for your interest! I would say my question wasn't exactly related to that. I meant having an AI helper that knows guidelines, manuals of styles, policies, etc. and helps the user follow them and face their technical difficulties that they may encounter along the way, for example, helping them use citation templates correctly or how and when to format a part of text as bold, how to sign up in discussions, etc. Its main purpose wouldn't be to help with the content per se but rather with using Wikipedia properly, policy/technically wise, what help venues like the Teahouse and wikimentors already do. — Klein Muçi (talk) 09:22, 8 March 2024 (UTC)
There are some learning helpers, they are not A.I. and do not need to be. An old one is The Wikipedia Adventure which teaches English Wikipedia guidelines and editing. Wikipedia:Growth Team features also teaches users through tasks, and it is upto your community to configure it in line with your policies. Edit check is the newest one, it is going to be a group of tests within the editors (VisualEditor and Wikieditor) that tell the user what to do. The first item in Edit Check will be an reference check, that tells an user to reference text if it is long enough. That length is configurable by your community. As for how to style citation templates, they should just let Citoid and RefToolbar autofill the citations for them.--Snævar (talk) 10:14, 8 March 2024 (UTC)
Yes, thank you! Even though I'm more old school myself, I've seen that new editors love the VE so those are already appreciated. The only problem is that all these tools lack what they wanted in the first place: An AI wikimentor.
They were being helped by us at that moment and they expressed the need to have the same help and guidance all the time in real time, a mentor, 24/7. That's how AI was brought to attention. - Klein Muçi (talk) 14:01, 10 March 2024 (UTC)
ChatGPT can already answer most questions related to wikipedia editing. You probably don't need a dedicated AI as all wikipedia policy and guidelines pages are open and were presumably part of GPT's training data. – SD0001 (talk) 11:11, 10 March 2024 (UTC)
I thought that as well. If GPT can be an AI wikimentor, then the question could be rewritten to ask for better integration of GPT with Mediawiki?
(BTW, I use GPT extensively myself but I've yet to try and ask it about policies or MOS so I'm not sure how it does with those de facto.) - Klein Muçi (talk) 13:55, 10 March 2024 (UTC)
Move with subpages succeeded – redirect not created for one subpage
I recently moved Draft:Article length bar to Template:Article length bar. This successfully moved 12 pages and created 11 redirects, with a missing redirect for Draft:Article length bar/styles.css. This is fine with me and I'm not asking for either a change in behavior, or an explanation; I'm posting this solely as an FYI to the community in case there are those who would want to know about this, as it does seem odd behavior. Adding Izno. Mathglot (talk) 02:51, 9 March 2024 (UTC) P.S. I have a Move succeeded screenshot showing one red link, if anyone wants it. Mathglot (talk) 03:04, 9 March 2024 (UTC)
I just created a manual redirect there—Draft:Article length bar/styles.css, not that I need it—so if the Move process wanted to do it, presumably it could. If one *shouldn't* create a redirect because of the .css extension, that's another matter, but then it shouldn't let me create one, either. Mathglot (talk) 06:39, 9 March 2024 (UTC)
The redirect doesn't work if you try to import CSS from the page so it's misleading to have a redirect. A redirect is just a wiki page with certain code which is interpreted in a special way by MediaWiki. You can save anything in wiki pages, including invalid CSS like #REDIRECT [[...]]. PrimeHunter (talk) 10:18, 9 March 2024 (UTC)
It's not exactly invalid CSS, but it's only partially valid. If we have a page Foo.css containing the single line
#REDIRECT[[Bar.css]]
what we have is (i) a valid ID selector matching any element having the attribute id="REDIRECT"; (ii) a valid descendant combinator (the space); and (iii) an attribute selector that would match any tag of the form <tagname Bar.css> or <tagname Bar.css="baz">, except that it is malformed by being enclosed in an extra pair of square brackets (how various browsers interpret those is not documented). What this "stylesheet" does not have is a declaration block (a pair of braces enclosing a declaration list); but whilst an empty declaration list is valid, I believe that the pair of braces is required. So consider it to be a do-nothing style sheet; but it certainly isn't a redirect in the MediaWiki sense of the word. --Redrose64 🌹 (talk) 16:12, 10 March 2024 (UTC)
I've deleted it. Indeed it is misleading to have a page like this. There isn't even a need for the original draft page redirects now that the page is main template spaced. Izno (talk) 16:51, 9 March 2024 (UTC)
For cases where there may be other uses of a given style sheet than an accompanying page/template, the original CSS file could be replaced with a CSS @import rule to include the file at its new location (unless $wgTemplateStylesAtRuleBlacklist has been configured on English Wikipedia to block it, assuming the page's content model remains sanitized CSS). However I agree in this case, there's no purpose for it. Draft pages should just have references to them updated. isaacl (talk) 18:59, 9 March 2024 (UTC)
The recent conversation on T334940 has made what people have been afraid of pretty clear: Extension:Graph isn't coming back any time soon, and probably never. I think it's about time we come up with a "temporary" solution.
We have two problems to solve:
A replacement for the old graphs needs to be made and then dropped in.
Editors should have a way to make new graphs in a standardized manner without resorting to a photo editor.
Ideally, these graphs are easily updatable by new editors. This would be quite difficult though. I think a reupload of a file is going to be the minimum possible 'resistance'.
While we're at it, it'd be nice if our solution worked for the other wikis too.
For problem 1, my first thought is for a bot to download and build the graphs locally, and then upload them as SVGs and replace them in the affected pages. A tall order. I'm willing to look into it but I find it unlikely to be within my skills.
Read mw:Extension talk:Graph/Plans. It covers what options there are instead of Extension:Graph and what those options can not do. There is also a list there, over the most used Extension:Graph templates on all Wikipedias. Snævar (talk) 00:04, 7 March 2024 (UTC)
For plain, horizontal bar graphs, I made for Category:Orphaned articles at the Progress section to "get it done". My initial thoughts were "something" better than "nothing". I understand this will not work for pie charts, & complex graphs. Regards, JoeNMLC (talk) 02:38, 7 March 2024 (UTC)
Pie charts will use Module:Piechart, an CSS+HTML based graph. Any interactive feature is gone. I did ask the devs if the graph system in Wikidata Query System could be used at phab:T357161, it would be for Wikidata-based graphs only. Snævar (talk) 10:06, 7 March 2024 (UTC)
What's especially embarrassing is the number of tickets such as T336595 and T222807 proposing alternatives that have been declined by the WMF as "we'll take a different approach", but no "different approach" has materialized. --Ahecht (TALK PAGE) 15:09, 7 March 2024 (UTC)
One a related matter, has there been any movement on the possibility of using some form of SVG inline in articles? While full SVG could have security problems, a sanitized SVG (akin to the CSS in templatestyles) could be safe. This would be useful for creating graphs. — Jts1882 | talk15:16, 7 March 2024 (UTC)
Keep in mind that SVG's, although they are uploadable are shown as png's. Although mw:Manual:$wgSVGNativeRendering exists to send SVG's to the client, it has not been enabled on WMF wikis. So, the landscape is not looking good. I mean, if they are not going to trust SVG's to be sent to clients from WMF wikis, then why should inlike SVG's be worked on? There clearly still is distrust towards SVG's. Your feature is covered in phab:T334953, phab:T334372 and phab:T66460. So far these tasks have negitive comments. I would say inline SVG is not going to happen. Snævar (talk) 12:59, 9 March 2024 (UTC)
The only negative comment I see across all of these tasks is specific to client-side inline SVG. As discussed on phab:T334372, it very much makes sense to have inline SVG that is still server-rendered. I would say this is quite feasible. The task just hasn't caught the attention of the right people yet. – SD0001 (talk) 06:56, 10 March 2024 (UTC)
I find that post perplexing. You were the only person at that phab task to mention server-side rendering - specifically, you wrote the inline SVG can be server-rendered. It doesn't need to render on the client. If the SVG is inline, it must be rendered client-side. --Redrose64 🌹 (talk) 22:03, 10 March 2024 (UTC)
Please read comments 2–4 in the task. What makes you think if it's inline, it must be client-rendered? Math and Score extensions today allow inline use of Latex/LilyPond, that doesn't mean they render on the client. – SD0001 (talk) 22:29, 10 March 2024 (UTC)
Please note the very wide shortcut boxes at the top of the example page (search for WP:NEWCSD and WT:CSD). Normally shotcut boxes are the same width as their text. In this case they're about triple or quadruple the width of their text. Any idea what is causing this? I think I saw this in one other place too but I forgot to write down the page.
I noticed undos now automatically make the revision id into a clickable link like some other Wikis did (I no longer need to do it manually or use my script, awesome :D) - where can I read about such changes, is there a changelog? – 2804:F14:80C6:A301:70C8:DCC8:4027:D6BB (talk) 00:54, 11 March 2024 (UTC)
I'm trying to fix two lint errors on Everybody's Got to Learn Sometime (unclosed div tag and unclosed table tag, as reported by LintHint), one or both of which is causing the article to display incorrectly on mobile, with all sections under "Other versions" getting collapsed into that section (very similar to this issue I previously asked for help with). The issue is, I can't find any div or table tags in the source, let alone any unclosed ones. What's the best way to find where exactly the issue is? Suntooooth, it/he (talk/contribs) 13:57, 11 March 2024 (UTC)
@Xaosflux and John of Reading: thanks for the help! I removed all the col templates - nothing seemed to break and it fixed the issue, so I'm not sure why they were there in the first place. Good to know that col templates can cause lint errors like that! Suntooooth, it/he (talk/contribs) 14:34, 11 March 2024 (UTC)
Tech News: 2024-11
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 12 March. It will be on non-Wikipedia wikis and some Wikipedias from 13 March. It will be on all wikis from 14 March (calendar). [9][10]
After consulting with various communities, the line height of the text on the Minerva skin will be increased to its previous value of 1.65. Different options for typography can also be set using the options in the menu, as needed. [11]
The active link color in Minerva will be changed to provide more consistency with our other platforms and best practices. [12]
Structured data on Commons will no longer ask whether you want to leave the page without saving. This will prevent the “information you’ve entered may not be saved” popups from appearing when no information have been entered. It will also make file pages on Commons load faster in certain cases. However, the popups will be hidden even if information has indeed been entered. If you accidentally close the page before saving the structured data you entered, that data will be lost. [13]
Future changes
All wikis will be read-only for a few minutes on March 20. This is planned at 14:00 UTC. More information will be published in Tech News and will also be posted on individual wikis in the coming weeks. [14][15]
The article has no co-ordinates, as it's a multi site establishment. {{infobox museum}} appears to automatically add a map but here has no co-ordinates to work on. I've added |mapframe=no to the infobox to switch the map off. Nthep (talk) 17:13, 12 March 2024 (UTC)
The infobox makes mapframe code which produces a map made by mw:Extension:Kartographer. Kartographer can pull data from OpenStreetMap. I don't know the details but I guess OpenStreetMap has data which reflects there are multiple WonderWorks locations, unlike the Wikidata item which only has coordinates for the Orlando, Florida location. The map ends up in water west of the Florida peninsula. PrimeHunter (talk) 20:37, 12 March 2024 (UTC)
Wicipedia Cymraeg (Welsh Wikipedia) does not have a gadgets tab at cy:Special:Preferences. Therefore, to use gadgets, it is necessary to load them into your personal common.js and/or common.css files. Gadgets may be imported from another Wikipedia, and this is easy for gadgets that are pure CSS - for example, for "Move section [edit] links to the right side of the screen", our MediaWiki:Gadgets-definition file has the line
to cy:Special:MyPage/common.css. Done, tested, working, no problem here.
However, if the gadget has a Javascript component, for example, "Add an [edit] link for the lead section of a page", our Gadgets-definition file has the line
The active one is Llywelyn2000 (talk·contribs), and if they wanted gadgets they would presumably have set some up by now (see Wikipedia:Village pump (technical)/Archive 180#Loading gadgets on another Wikipedia from four years ago). Based on that, I have done this, but I don't know if that's the correct way or not. It seems to work, but I don't know if it's causing undesirable side-effects, or is using outdated code that may fail at any time. It would have helped a lot if you had said "using this basic framework, you pass in these values here and here. --Redrose64 🌹 (talk) 01:03, 14 March 2024 (UTC)
Templates stop working after a certain number (of templates) is transformed (timeout/load protection?)
Resolved
The page in question (Missing Wikipedians) is a large list of Wikipedia users, Template:User2 is used extensively throughout the page.
Somewhere around the middle of this section, templates turn into link to the template used, instead of whatever should've appeared in place of said template.
After a multi RM, I went back to fix double redirects. When doing so, I discovered a possible bug in the "What links here" function.
What happens is that there first seems to be one [double] redirect only. I fix it, and then return to the "What links here" special page. I refresh: the changed redirect now shows in expected place – but then one or two new redirects appear in the list!
Why didn't they show before? I think the issue is somehow related to the sorting order in the "What links here" page: after the "Wikipedia" article name space, which is shown last (possibly except for "Wikipedia talk"), the function does not expect more pages – so it doesn't even try. The list in the function wasn't always sorted on article name space, was it?
I have saved the last article in the multi RM for a technician to "debug" if they wish: List of people associated with Wadham College, Oxford. There is a single double redirect (and articles linking to it), but I expect more to appear after it's fixed.
P.S. This appears – at least to me – unrelated to the 500 limit on showing links to redirects. Few articles link to the articles in the RM, even if you include links to redirects. HandsomeFella (talk) 07:00, 14 March 2024 (UTC)
Is it possible that the unlisted pages were triple redirects, and that your fixing something else turned them into (less bad) double redirects? WhatLinksHere lists double redirects, indented, but I don't think it recurses into them to list triple redirects. For example, if R3 redirects to R2 redirects to R1 redirects to article A, R2 is listed indented within R1 but R3 is not listed. If you then fix R2 to redirect directly to A, R3 will appear indented within the top level redirect R2. Certes (talk) 09:44, 14 March 2024 (UTC)
Edit summaries forgotten
Until late last night when I started typing in an edit summary field it came up with precious summaries that started with the same letters. This was very useful for some of the work I do, eg fixing Category:Harv and Sfn no-target errors. At some point late last night it stopped doing this, and likewise this morning. I haven't changed any settings on WP or on my computer. How do I make it start remembering edit summaries again? Thanks, DuncanHill (talk) 11:27, 10 March 2024 (UTC)
It does not remember your past edit summaries because something cleared or stopped using your autofill cache in your browser. It is only possible to help if you say what browser you are using. Maybe the website of the browser knows more than people here. You can ask here for a list of your edit summaries, if you find that useful. Snævar (talk) 14:19, 11 March 2024 (UTC)
This is not a feature coming from us. Browser-configuration of such a feature is using in the "autofill" or "forms" configuration of your browser. Certain privacy extensions may suppress this as well. — xaosfluxTalk13:57, 13 March 2024 (UTC)
As I said, I haven't changed anything. If it helps, no other forms or autofill behaviour has changed, even on Wikipedia. Just edit summaries. DuncanHill (talk) 14:06, 13 March 2024 (UTC)
I don't know what discussion tools are, so presumably the standard editor. The change in behaviour happened in the course of the evening. DuncanHill (talk) 14:31, 13 March 2024 (UTC)
I don't use any Beta features. On the Editing prefs page under "Discussion pages" "Enable quick replying", "Enable editing tools in source mode", and "Enable topic subscription" have all been ticked (but not by me, I am sure). The problem is on all pages, not just Talk. DuncanHill (talk) 15:01, 13 March 2024 (UTC)
Find and click on three dots in the top right of your browser window, click "Settings". On the page that appears select "Privacy, search and services" on the left side. Go to the "Clear browsing data" heading. Open "Choose what to clear every time you close the browser". Find if the option for autofill is on or off (should be off). Snævar (talk) 10:56, 14 March 2024 (UTC)
It is off. It's always been off. I think I mentioned that "I haven't changed any settings on WP or on my computer". The only change in behaviour has been to one field on Wikipedia. DuncanHill (talk) 11:01, 14 March 2024 (UTC)
Gadget that helps edit templates via TemplateData
TemplateWizard is great when you want to add a new template, but it doesn't work when you want to edit an existing template. Is there any existing tool or gadget that can help here? VisualEditor is great but it doesn't work in talk/wikipedia namespaces. ԱշոտՏՆՂ (talk) 03:57, 14 March 2024 (UTC)
As to how I found it, I opened "inspect"/devtools on Chrome (F12?) and CTRL+F searched for "1985 PBA Reinforced Conference Finals" in the Elements tab until I found what element it was.
Is their any script/ template on Wikip so if put in a page, every time any user refreshes/ visits the page, it auto purges. For example I could put it in my random number generator, so every time anyone visit/ refresh the page, its gets purged. ExclusiveEditorNotify Me!11:01, 14 March 2024 (UTC)
@Saqib: Your watchlist options may exclude the page. For example, I exclude my own edits. If you do the same then your edit to Muhammad Aurangzeb won't show up and the page might not be on your watchlist unless the time period covers the previous edit too. Certes (talk) 13:03, 14 March 2024 (UTC)
@Certes: If you're suggesting that pages last edited by me won't show up on my watchlist, then why do the rest of the pages, where I'm also the last editor, appear on my watchlist? --Saqib (talk) 14:14, 14 March 2024 (UTC)
I can't see what options you have set, so I'm making blind guesses and may well be wrong. In the "Watchlist Options" panel, on the "Hide:" row, I have a tick to the left of "my edits". That means a page doesn't appear if its only recent edits are mine. I still see pages other people edited, even if I also edited them. This may or may not be causing what you see, or there may be another of the Hide: options filtering out the pages. If not then I apologise for wasting your time. Certes (talk) 15:01, 14 March 2024 (UTC)
"Maximum number of changes to show in watchlist:" - 250
"Expand watchlist to show all changes, not just the most recent" - enabled
"Use non-JavaScript interface" - enabled
"Hide minor edits from the watchlist" - disabled
"Hide bot edits from the watchlist" - disabled
"Hide my edits from the watchlist" - disabled
"Hide edits by anonymous users from the watchlist" - disabled
"Hide edits by logged in users from the watchlist" - disabled
"Show only likely problem edits (and hide probably good edits)" - disabled
Viewing the page history shows five edits for 14 March 2024 (03:27, 06:33, 17:23, 20:19, 22:42) but with the above settings, plus on-the-fly settings for 3 days and (Article) namespace, my watchlist shows only four edits for the same date (03:27, 17:23, 20:19, 22:42). There are none missing for either 13 or 15 March. I can see nothing in the flags and tags for the 06:33 edit that might cause it to be filtered out. --Redrose64 🌹 (talk) 12:00, 15 March 2024 (UTC)
We have encountered a strange technical bug while inserting new templates into the tables for this article. The issue is visible beginning with 1978 on the Pairs table. I do not see where something was entered wrong at that point that would cause all of the subsequent templates to not display properly. Any advice would be appreciated. Pinging Hyperion82. Bgsu98(Talk)20:43, 14 March 2024 (UTC)
I sure would appreciate any assistance in this matter. I'm sure the user who created that template would not mind at all. Bgsu98(Talk)21:33, 14 March 2024 (UTC)
Seems like this line of code should change to "false" like the rest so the check doesn't occur for "icon". Not sure why it is different or why the check is even needed?
function p.icon(frame) return p._main(frame, 'Flagicon', 'cxxl', true) end
I somewhat understand what is happening, but I don't understand why it is happening. The Module:flag braces appear to be properly closed before they get to 3= and dap=, which are intended as parameters for {{FS medalist/sandbox}}, so I don't see why Module:flag is able to see those 3= and dap= arguments. I'm missing something. – Jonesey95 (talk) 05:32, 15 March 2024 (UTC)
You can also add |frameonly=true to the module call to prevent it from looking at the parent template's parameters. --Ahecht (TALK PAGE) 17:32, 15 March 2024 (UTC)
Substing the whole medalist section, apart from cite web and the "Cumulative medal table" section (they do not like being subst), brings PEIS down to 1,982,442/2,097,152 bytes. Snævar (talk) 21:48, 14 March 2024 (UTC)
Hello not sure where to put this
Where do I go to ask WMF to support WikiLovesiNaturalist or similar in maintenance, uptime, expansion? The iNaturalist to Commons pipeline is precious and invaluable and having it kinda automated with license checks and all the metadata connected is Very Very Good. Not sure how to pursue this but it's spring and my social media is rich with "check out this rare wildflower I saw" posts and I want to create stubs for them all but WikiLoveiNat is having uptime challenges which slows down the stub-illustration process. Thanks in advance for guidance. jengod (talk) 00:13, 11 March 2024 (UTC)
I use #ifexist when I must in templates, aware of its status as an WP:EXPENSIVE parser function. I attempt to minimize its use, and I document it on the /doc page so users are aware of the implications. However, it recently occurred to me that I can do better. The huge majority of the time, I don't care to distinguish between the cases, a) page does not exist, and b) page exists but is empty. Given that, if PAGESIZE is not expensive, I plan to replace all of my #ifexist functions with an #ifeq PAGESIZE instead:
{{#ifeq: {{PAGESIZE:Qkxjwuuu}} | 0 | ∄ or empty | non-empty}} ⟶ ∄ or empty
{{#ifeq: {{PAGESIZE:User:Mathglot/sandbox/emptypage}} | 0 | ∄ or empty | non-empty}} ⟶ ∄ or empty
Am I missing something, or is this a good strategy for reducing the number of expensive parser functions in templates where the conditions 'pagesize=0' and 'page does not exist' are handled equivalently?
P.S. I tried alternatives: #if won't work, cuz a '0' string is true; and #ifexpr won't work, unless you formatnum-protect pagesizes > 999; #ifeq was briefest. Mathglot (talk) 03:39, 15 March 2024 (UTC)
"Expensive" is pretty relative - the cost isn't really in counting or anything in the case of ifexist but in the fact that the system needs to make a trip to the database to know whether the page exists. The valuable thing is that ifexist will trigger updates in the page it's used on when the page you're checking for existence starts existing. IDK if that is guaranteed for PAGESIZE. I also don't know if PAGESIZE needs a DB call; it's not marked as such, but that doesn't mean much.
That said, unless you're making a template that will be called many times a page, one or two checks for existence breaks no bank (we're allowed up to 500 expensive functions a page). Izno (talk) 04:17, 15 March 2024 (UTC)
Thanks, yes, I know about checking the PP limit report, and some of these templates are conducive to being used in a table of lots of articles so could eat up a lot of the 500 limit, possibly exceed it although that hasn't happened yet. Also, the ones I have in mind are designed chiefly for Talk space, so it's less serious if hitting a limit does break the page, but still. Maybe Certes or xaosflux would know about the DB call question? If it's no better than #ifexist, then no point in changing these templates, but if it is better, there could be a real upside, and a tool to improve a lot of templates. Mathglot (talk) 05:13, 15 March 2024 (UTC)
If you're not bothered about the page's existence being updated (perhaps you even want to keep a historic record of whether it existed at time of writing) then you could subst: the #ifexists (or #ifeq workaround). Then you could add pages in batches of much less than 500, so the one-off parsing would work each time. I'm not sure whether this fits with your use case. Certes (talk) 18:02, 15 March 2024 (UTC)
Nice tip. Wouldn't work exactly for my use case, but a modification of it might. It involves a trick I saw somewhere which saves a subst without executing it the first time (maybe split up by a self-closing noinclude in the middle of it, or something like that), and then next save, it is substed. This would allow what you are saying to happen in two saves, with the first one containing a trace of the visible subst, meaning we could wait a week or whatever period, revert to the first save, let it subst again, thus saving a weekly snapshot of existence, so to speak, which might be good enough. Does that sound like it would work? Mathglot (talk) 23:29, 15 March 2024 (UTC)
The limit is there for a reason. People trying to bypass the limit are essentially trying to break the servers. Which means that such a hole will be plugged. MediaWiki is not a generic database or generic compute platform. If you want to do very complex things, at some point you will have to write an extension and take into account the many restraints that apply to efficiently serve up data. —TheDJ (talk • contribs) 08:41, 15 March 2024 (UTC)
{{cite canlaw}} does not support |ref=. You can wrap the {{cite canlaw}} template with {{wikicite}} to work around that limitation or you can edit {{cite canlaw}} to create an anchor ID from |ref=. {{wikicite}} is the simpler solution.
maybe that is an unusual comment for this talk page. Talk:Limburgish is a talk page which is not only difficult to read and not formatted properly, all of which partly is caused by me. What can I do to render the talk page in line withg the rules?
By now, further parts of the article have been removed by bot. Half a year ago, an author using changing IP adresses caused hustle across Wikimedia by forcing decisions. This user seemed to refuse to differentiate between German Wikipedia and other Wikimedia projects. Sarcelles (talk) 21:02, 14 March 2024 (UTC)
I would like to know how I can rewrite its content with respect of both intelligibility and the rights of other authors. Sarcelles (talk) 23:39, 16 March 2024 (UTC)
Magic word that only removes the inline ToC
Recently, the inline TOC at WP:RFA2024/I was replaced with a manual one. This was done through the __NOTOC__ magic word. Unfortunately, this also disables the floating ToC on V22. Is there a magic word to preserve that? Or maybe a setting? Aaron Liu (talk) 18:17, 16 March 2024 (UTC)
Why not have both? The sidebar TOC in Vector 2022, the default skin, is useful, since it stays visible when scrolling a long page and is independently scrollable. I would remove the NOTOC. – Jonesey95 (talk) 00:29, 17 March 2024 (UTC)
But that would also cause a duplicate inline ToC for the hundreds of people not using V22.Maybe we could wrap a display:none across a __TOC__? Aaron Liu (talk) 00:30, 17 March 2024 (UTC)
That seemed like it worked. Are there any possible accessibility concerns for this approach? Is there a more suitable HTML5 element than <div>? Aaron Liu (talk) 00:34, 17 March 2024 (UTC)
Subtitle and jQuery, again
A while ago, I asked about how to pass a jQuery object into mw.util.addSubtilte. @Nardog suggested basically converting the object into an HTMLElement through accessing [0], which worked. However, it has a weird caveat: it duplicates the element when I run .html(newHTML) or similar functions on it, and the duplicated element will be nested under the original element. His initial suggestion of wrapping it inside a parent element does the same thing. See User:Aaron_Liu/Watchlyst_Greybar_Unsin.js#L-102 for my current implementation. Is there some way I could deduplicate this thing? Aaron Liu (talk) 21:57, 16 March 2024 (UTC)
It looks like you're returning what is supposed to be the outer HTML in getWatchlyst(). .html() replaces the inner HTML, not the outer HTML (which you can't do without replacing the element altogether). Nardog (talk) 01:48, 17 March 2024 (UTC)
It seems as if mobile users are not seeing the full talk page, instead getting everything collapsed to a "learn more about this page" message. I found that not only my talk page does this [17], but other stylized talk pages like [18], etc.
I get that the mobile experience sucks on Wikipedia, but this might be something that might need addressing ASAP. Can we maybe look into it? Maybe it needs a Phabricator report. AwesomeAasim20:31, 16 March 2024 (UTC)
@Awesome Aasim: Without looking at the details, there are three things that might be causing this: (i) the use of level 1 headings; (ii) the placement of the TOC in the third section, instead of before the first heading; (iii) the use of unclosed <div> tags in the first section that persist to the foot of the page. --Redrose64 🌹 (talk) 20:43, 16 March 2024 (UTC)
@Redrose64 If you see Cyberpower's talk page, which I linked to as a second example, the same notice is there. It is some sort of HTML thing happening I think that is confusing mobile. It is not happening on your talk page, either. I checked another talk page and that one functions correctly. It is some half baked piece of code that is causing this. AwesomeAasim22:48, 16 March 2024 (UTC)
@Jroberson108 That is not much of a "fix"; rather a bodge around a broken patch on mobile. It has been fine for mobile users until recently... BTW MW auto closes div tags, etc. at the end of pages I believe. RR's talk page BTW does not have any of this "Learn more about this page" business; I think what is supposed to happen is the first section is supposed to be displayed up there. But it isn't, and here we are.
Maybe I can get around this with templatestyles.css for now but it still feels very bodgy. There are dozens of Wikipedian talk pages that are decorated in a similar manner to mine; if all of them are broken then it is something that should be reported to Phabricator. AwesomeAasim01:30, 17 March 2024 (UTC)
As an aside, autoclosing of div tags by MediaWiki hasn't been my experience in the past, for talk pages using it to put a background box around the main content area. Is that a behaviour that has changed? isaacl (talk) 02:18, 17 March 2024 (UTC)
@Isaacl I just tried in my sandbox with this markup: <div><span></div></span> and the DOM shows them as this: <div><span></span></div>. That might not mean that it was autoclosed in the source but something is going on to fix this. AwesomeAasim04:20, 17 March 2024 (UTC)
There are other issues with your page on Minerva like the "Add topic" button appearing over the categories unless the level 1 "Talk" section is opened. This may be due to having multiple level 1 headers (<h1></h1>), something against WP:LEVELONESECTION. Also, if you are going to add HTML instead of wikitext, try to keep it valid and test it in the different skins. See Help:HTML in wikitext#div. BTW, the main content area you are allowed to edit isn't the end of the page, so invalid markup might affect what comes after it. Jroberson108 (talk) 03:43, 17 March 2024 (UTC)
The opinions of more experts would be greatly appreciated concerning any possible improvements.
This is a template I started, and has been improved by Jroberson108. Some tests are being run, but I am the only iphone user doing the tests, and Jroberson108 is the only Android phone user doing the tests so far.
We need other cell phone users to look at the sandbox pages in their cell phones in both portrait and landscape orientation. The current template styles work very well now for iphone users (at least for me using iphone SE 2020 in mobile Safari, Firefox, Edge, Chrome, Opera) no matter the width of the table. In both portrait and landscape view. I do not need to zoom out, or change the font size.
I am worried that there may be less iphone users able to see sticky headers on tables with these new styles. Because some of the new styles are specific to my iphone SE 2020. So I would like some other iphone users to compare the results of the old and new styles:
Template:Sticky header/testcases - testcase styles. Intro may be incorrect since changes have been made. Not as many table widths.
I would also like some other Android phone users to look also. And tell us if the new styles are better or worse in portrait and landscape views. Specifically, one should not have to zoom or change font size to see sticky headers. But it may be required. Table widths shouldn't matter either. But they may. Be specific when comparing the old and new styles.
The main effect of the new styles is to allow non-sortable tables to have sticky headers on desktop and cell phones. But that was never a big problem because it is easy to add class=sortable to a table. And {{sort under}} if necessary.
If the new styles affect iphone and Android phone users positively, then the new styles should go live. But if they are negatively effected by the new styles, then the new styles need to be improved. And advice from experts is requested in any case. --Timeshifter (talk) 13:40, 26 February 2024 (UTC)
I don't have time to read through the (extensive) discussion on the template pages, but here are my observations (appropriately displayed in a table):
sandbox244 (old)
sandboxen243 & 245 (new)
Firefox Desktop
Only sortable tables have sticky headers
All headers are properly sticky
Firefox Android
Only sticky if the table is sortable and I (pinch) zoom out so the full width of all tables is visible (because apparently those don't scroll horizontally?)
None sticky in portrait, all sticky in landscape
My viewport is 396px wide in portrait, and 760px wide in landscape. (...which is really weird scaling, because the physical display is 1080x2340. Huh.) Hopefully that's of some help. LittlePuppers (talk) 23:10, 26 February 2024 (UTC)
LittlePuppers. Thanks! Am I correct to assume that all table widths worked in Firefox Android landscape without zooming? Were any of the tables wider than landscape view? I just added some columns to a couple wide tables to make them into really wide 12 or 13-column tables. Here: User:Timeshifter/Sandbox243. --Timeshifter (talk) 00:23, 27 February 2024 (UTC)
User:Timeshifter/Sandbox243#Test sticky-header (sortable) is the only one wider on my Android Chrome landscape where I have to zoom out to make it sticky. It pushes beyond the main content area making the whole page wider, but the text is still readable. Without zooming, the edge of the screen ends inside header 9. "Test sticky-header (no caption)" too, which the edge ends inside header 12. Jroberson108 (talk) 01:15, 27 February 2024 (UTC)
It appears that with either version of the template (old or new), if there is any table on the page wider than the default width, no headers will be sticky until the page is zoomed all the way out. LittlePuppers (talk) 02:03, 27 February 2024 (UTC)
I agree, for User:Timeshifter/Sandbox243 in landscape you have to zoom all the way out for a table to be sticky. Also, if all the sections are open (all tables in view), then no tables are sticky unless you zoom all the way out.
Compassionate727. Thanks! Did you check the the old and new styles by checking sandboxes 244 (old) and 243 (new)? It is the comparison that we need the most. Do you see sticky headers on the widest sortable tables without having to do anything special? On both sandboxes? --Timeshifter (talk) 21:24, 3 March 2024 (UTC)
Erm, I only looked at 243. I looked at 244 just now and the headers are not sticky. (I thought that was expected?) The width of the table doesn't affect anything beyond the fact that I have a small screen and wide tables are inherently less readable anyway. —Compassionate727(T·C)00:12, 4 March 2024 (UTC)
Compassionate727. Thanks again. It looks like your iphone 6s screen and viewport is the exact same size as my iphone SE 2020 screen and viewport:
On my iphone in Safari, Firefox, Chrome, Edge, and Opera: The wide sortable table is sticky in sandbox 243 and sandbox 244. --Timeshifter (talk) 12:57, 4 March 2024 (UTC)
Sticky headers work in those sections in Chrome and Safari. In fact, they work in every section in sandbox 243, but not 244; in sandbox 244, all of the tables in sections 1, 2, 3, 7, and 8 are NOT sticky in both Safari and Chrome. —Compassionate727(T·C)21:12, 4 March 2024 (UTC)
Thanks Compassionate727 for the full review of all sections! The current CSS does not work on non-sortable tables. Those are the sections in 244 that are not working for you. I get the exact same results as you.
I am wondering if only users with small iphones get such good results. The testcase CSS is specifically pointed at iphones with the smaller viewport size found in iphone 6, 6s, 7, 8, SE 2020, and SE 2022. They all have the exact same screen size and viewport size. See:
I don't see any reason not to go live with the new styles. No issues have been found. If there are issues, then editors can simply bring it up on the talk page. Jroberson108 (talk) 07:02, 5 March 2024 (UTC)
As I stated before, if the current styles work perfectly (for sortable tables) on all iphones, but only for smaller iphones with the proposed styles, then the new styles are not a net improvement. In that case the new styles only help with nonsortable tables. Nonsortable tables were not a serious problem in comparison. Because it is easy to make a table sortable. And sortable in a way that does not make the table wider (via {{sort under}}). Plus the new styles would break some of the tables; those with multiple header rows. We would have to go back and change the class on those tables from class=sticky-header to class=sticky-header-multi. So let's just relax and wait for some later iphone model users to show up. If the new styles work for them, then the new styles are a net benefit, and I would support them. --Timeshifter (talk) 13:00, 5 March 2024 (UTC)
Well, FWIW, they work properly when I switch to mobile view on my laptop. Presumably if they work on both the smallest phone screen and a computer screen, they'll work on anything in between? —Compassionate727(T·C)15:04, 5 March 2024 (UTC)
What brand and model is your laptop? It is possible to switch to mobile view from a desktop PC too. Link is at the bottom of all Wikipedia pages. But I don't think it gets the same results as the mobile view on a cell phone. I vaguely remember that problems ensued when I tried this method before. --Timeshifter (talk) 15:16, 5 March 2024 (UTC)
And if they don't, then editors can easily mention it on the talk page like any normal issue, which these changes are additive. It's not a big deal. If the old styles are kept, then the same mobile fixes would need to be applied to fix Android issues, so comparing them like this is nonsensical. Also, mobile isn't the only fix, so I wouldn't get hung up on it. Jroberson108 (talk) 15:17, 5 March 2024 (UTC)
Apparently, there is no improvement for Android sortable tables. LittlePuppers wrote: "It appears that with either version of the template (old or new), if there is any table on the page wider than the default width, no headers will be sticky until the page is zoomed all the way out." You agreed with LittlePuppers.
We are not sure if there is any improvement for sortable tables on most iphones. We don't know whether sortable tables are sticky on most iphones (those larger than my small one) on both the current or proposed styles. --Timeshifter (talk) 15:36, 5 March 2024 (UTC)
It seems like you don't understand the Android issues either. When tables are sticky on Android, horizontal scroll on wide tables don't work. LittlePuppers and I have both said this. Minerva adds horizontal scrolling to tables for an improved mobile experience on small screens, which occurs at Minerva's device break point (width <=720px). On Android, sticky breaks that preexisting feature making the experience worse and causes a readability issue when zooming out. It's not a matter of "no improvement", but "worse". This may be the case on other non iPhones. You mentioned that horizontal scroll still works on your iPhone, so exceptions were added for Minerva's small screens. You wanting every iPhone model in existence to test this is ridiculous. Again, if there are other issues, then it can be mentioned on the template's talk page and those changes would be additive. Jroberson108 (talk) 16:08, 5 March 2024 (UTC)
I am looking for iphone user(s) with a bigger screen than iphone SE 2020 or iphone 6s. I am not sure if the current CSS, or the testcase CSS, works on bigger iphones at all. Or if it does work, how well it is working. Because some of the CSS is specific to my iphone viewport. See previous discussion. This is not a voting RFC. This is just another attempt to get some input from other iphone users. I left a message awhile back at the computing reference desk, but no one showed up here from it. --Timeshifter (talk) 13:22, 4 March 2024 (UTC)
Actually, I like it. RfCs should be a method of requesting comment from other users when a large scale is needed, not a vote on policy. The current system is far too bureaucratic. 🌺 Cremastra (talk) 19:58, 13 March 2024 (UTC)
I have seem many RFCs that lasted less than a week. I already tried getting more iphone users a couple other ways. I just asked for help at Help:Desk. Iphone users: To make this as simple as possible please tell us if sticky headers work without problems in this section:
Thanks Paper9oll! So those wide tables had sticky headers in that specific sandbox section in both sandboxes? In both portrait and landscape orientation on your iphone?
Thanks again Paper9oll. Well, that's too bad. That means that the proposed styles are a step backwards for most iphones. I (with my smaller iphone) see the same thing you are seeing with the current styles for sortable tables (that section in sandbox244). With the current styles I see sticky headers working perfectly in sortable tables in landscape and portrait view no matter the width of the table (that section in sandbox244).
Most iphones in use nowadays are bigger than my smaller iphone SE 2020.
For sortable tables the proposed styles work the same as the current styles for my smaller iphone. This is because the proposed styles address my specific smaller viewport size. --Timeshifter (talk) 14:12, 7 March 2024 (UTC)
What about "patience" do you not comprehend? You are approaching WP:NPA and WP:TALK problems again in your passive aggressive tone. Please remain collegial in our discussions. What's the rush? Why go backward in some areas if it is not necessary? If you truly believe that you or someone else will figure out a solution for all iphones soon, then we can wait. If it is going to take months or years to improve, as it did in the past with sticky headers, then that is even more reason to wait. It is easy to make tables sortable. I did it several times in order to use the sticky headers template. And {{sort under}} makes it possible to do so without increasing table width. So right now, nothing is really "broken" with the current styles in any serious way. --Timeshifter (talk) 14:41, 7 March 2024 (UTC)
I have been trying to wrap my brain around those exceptions in the proposed CSS:
screen and (width: 710px) and (orientation: landscape),
screen and (width: 667px) and (orientation: landscape),
screen and (width: 375px) and (orientation: portrait)
The pattern is obvious for my iphone SE 2020 (375x667px). See my viewport listed here:
I wish it were that easy, but they gave their landscape viewport width as 710px and their test worked. No exceptions are needed for a width over 720px, so a width of 932px is already covered and redundant. If you recall, your iPhone viewport height was different from the listing too. Multiple browsers were a bit different in viewport height, but the width was consistent. Jroberson108 (talk) 20:59, 7 March 2024 (UTC)
So this block resets the mobile table's BACK from scrollable blocks to normal tables... in orientation mode for very specific widths ... I don't get why.. why not for all widths over portrait phone sizes ? What would break on my much larger desktop screen ? I'm confused. —TheDJ (talk • contribs) 22:19, 7 March 2024 (UTC)
@TheDJ: No issues on desktop. Basically overriding Minera's device breakpoint of <= 720px causes issues on Android and maybe some other untested devices. The issue is that the table's horizontal scroll doesn't work when sticky, which a wide table pushes beyond the main content area making the page wider, and requires zooming out to see the entire table before it's sticky making the text on the entire page more unreadable the wider the table is.
Apparently this same issue doesn't occur on iPhone since the horizontal scroll works. The code Timeshifter posted comes from the sandbox (see comments) at the bottom and is an attempt to get it working on only iPhone at that break point, which I know widths alone aren't enough to target only iPhone, but its all we have since he wants it working. Fixing horizontal scroll on Android would be ideal, but the only solution I've found is moving the horizontal scroll to a div wrapper, which isn't possible with this template. The div wrapper solution is something I did on the COVID sticky styles that you helped fix. Jroberson108 (talk) 23:16, 7 March 2024 (UTC)
@TheDJ: I created User:Timeshifter/Sandbox246 so I could test your sticky gadget found in gadget preferences. The sandbox has no sticky templates. On my Win 10 Pro desktop in Firefox your gadget worked on all tables there regardless of width (including the 16 column table). Except it did not work with nonsortable plain tables. It worked with sortable plain tables. And it worked with nonsortable wikitables. On my iphone it did not work in that sandbox in Safari and Firefox. In both portrait and landscape view. --Timeshifter (talk) 23:39, 7 March 2024 (UTC)
@Paper9oll: Could you check another browser besides Safari? What is its viewport here:
And are the tables sticky in sandboxes 243 and 244 in landscape and portrait view? Maybe like with my iphone SE 2020 the landscape viewport width stays the same across browsers.
Your screen size (6.7 inches) is the largest size iphone screen size. So we would need viewport sizes for all iphones. I count 10 different iphone viewport sizes here (sort that column):
Thanks Paper9oll for that thorough report! I wonder why Chrome did not work in landscape in sandbox243? The viewport width is the same as the others.
And in Edge did it work for narrow tables in either sandbox in landscape? Please close all the sections, and then go to a section with narrow tables. We have seen this sometimes where any visible table wider than the screen causes all tables not to have sticky headers (even narrow tables on the same page).
@Paper9oll: Thanks for the extensive testing. Edge landscape seems to be doing some weird stuff like maximizing the use of the landscape viewport area or something, so I can't speak to that. The Chrome landscape result does seem odd since it's also 710px.
Making it so Android still has horizontal scroll on tables and sticky works on iPhone for Minerva width <= 720px is becoming increasingly difficult. Ideally, the Android horizontal scroll should be fixed if possible so targeting only iOS isn't needed.
Maybe TheDJ will be able to figure out a fix for the horizontal scroll or an easier way to target only iOS perhaps with a combination of @supports (-webkit-touch-callout: none), @query, and other -webkit styles? Maybe there is a class that MediaWiki adds to the html or body element to identify iOS that I'm unaware of?
Doesn't seem like TheDJ has the time right now, so Timeshifter it seems like your only blocker is the new styles not working on 100% of the iPhones. I can modify it so it works on all iPhones and the Android issue persists just as it does on the live styles. This way the rest of the fixes and improvements can move along. Hopefully this satisfies everyone and TheDJ can find the time one day to fix the rest. Jroberson108 (talk) 02:49, 9 March 2024 (UTC)
I prefer to wait until the other 8 iphone viewport sizes are sticky in the proposed styles. I don't want to go backward on iphone sticky tables. Right now with the current styles they are working amazingly well. Considering how difficult it has been to get people with 2 iphone screen sizes (4.7 inch and 6.7 inch), it could take months to find people with the other 6 screen sizes, and 8 viewport sizes. As I wrote before I count 10 different iphone viewport sizes here (sort that column):
Maybe while looking for them someone figures out another solution. I think maybe we should keep the current styles, and you and/or others can concentrate solely on Android. And not worry about nonsortable tables at all. I think Android tables being sticky without problems is far more important. If we end up with Android and iphones being sticky without problems, but we can't combine that with nonsortable tables, then I am still very happy with that. It would be a great improvement. --Timeshifter (talk) 04:46, 9 March 2024 (UTC)
@Timeshifter As requested, Sandbox245 and Sandbox247 is working on both Chrome and Edge in both orientation with no issues. @Jroberson108 As for Chrome, I forgot to mention that on Sandbox244 and Sandbox243, in landscape, it will autozoom out to fit the entire table into the screen itself as if I'm viewing it in Wikipedia's desktop view hence maybe that explain why despite having same 710px as Safari which doesn't do autozoom out to fit. —Paper9oll(🔔 • 📝)06:43, 9 March 2024 (UTC)
@Paper9oll: Yeah, sounds like the Chrome width changes, but you can't get the width value on the other site since it's content isn't wider than the screen. To make matters worse, that width would vary based on how wide the table is when the autozoom out happens. Jroberson108 (talk) 07:41, 9 March 2024 (UTC)
@Timeshifter: I'm not sure what you mean by "backward on iphone sticky tables"? The change I propose on the sandbox styles is to make sticky work on all iPhones without having to add viewport widths for each device. The Android horizontal scroll issue would still exist. This part would work just like the current (live) styles, so all iPhones remain sticky.
I'm not abandoning the fix for Android, just removing it as a blocker so the other fixes and improvements can go live. The Android fix can still be worked on and added at a later time once fixed. I'm still hoping TheDJ or someone else might have a better fix that doesn't involve device widths, whether it be now or later. But, the other parts of the sandbox styles don't depend on the Android fix. Jroberson108 (talk) 07:25, 9 March 2024 (UTC)
@Timeshifter: I updated the sandbox styles so you can see what I'm talking about. The new styles should work on all iPhones now without needing to add viewport widths specific to devices. The same way it works on the current (live) styles. Fixing the Android horizontal scroll issue, which the issue also exists on the current (live) styles, is a secondary task. The sandbox styles can now replace the current styles. The Android fix can still be worked on separate from the rest of the styles whether it be adding the device widths back and continuing with that or some other solution. Please test and let me know if it works. Jroberson108 (talk) 14:12, 9 March 2024 (UTC)
Testing proposed styles #2
Jroberson108 and Paper9oll. I cleared the cache of all 5 browsers on my iphone SE 2020: Safari, Edge, Firefox, Opera, and Chrome. See:
At User:Timeshifter/Sandbox243 the proposed styles #2 work amazingly well. All tables are sticky no matter the width. Whether in portrait or landscape orientation.
Class=sorttop is not a problem except with class=sticky-header-multi (same as the first proposed styles). This is true for both wikitable or plain table. The table is still sticky no matter the width. But the sorttop rows with that class are sticky after sorting.
@Paper9oll: Can you test in all browsers too? If you get the same results, then this is an improvement over the current styles since it works with nonsortable tables too. And so I would support going live with it.
I agree that sorttop is a known issue on the current and sandbox styles, and not something fixable (it has a bug report). On Windows and Android, more things work and are sticky. On Android, the table's missing horizontal scroll and having to zoom out on wide tables for sticky to work is the same on the current and sandbox styles, so no change, as expected. No zooming out is needed if the only table that's visible is narrow and fits the portrait width like in "Test sticky-header (sortable). Narrower tables", so font size is unchanged and remains readable when sticky, which is the same in both. Jroberson108 (talk) 16:30, 9 March 2024 (UTC)
@Timeshifter Not sure what to test so I just expand every section on Sandbox243 on Safari, Chrome, Firefox, Edge, and Brave. Working in both orientation for all 5 browsers. —Paper9oll(🔔 • 📝)06:11, 10 March 2024 (UTC)
@Timeshifter, Paper9oll, and LittlePuppers:Draft:Template:Sticky_header/doc is a draft of the new documentation that will replace the current one to explain the new styles. Feel free to edit it. Before replacing the live doc, the "/sandbox" text will need to be removed.
Most of this was discussed at Template talk:Sticky header#Template improvements, but I'll re-explain it so everyone is aware. After going live with the new styles, existing tables using the obsolete sticky class (used on row wikitext) will need to change to the sticky-header class (used on table wikitext). Also, existing sortable tables with more than one header row (multiple) will need the sticky-header class changed to the new sticky-header-multi class. The large majority of the tables using this template have one header row and use the sticky-header class, so they won't change.
If you think something might have been overlooked and more style changes are needed even if it is a better class name, then now is the time to mention it. Jroberson108 (talk) 16:52, 10 March 2024 (UTC)
It's up to you. If you feel comfortable with the Android situation without additional testers, then go live. If not, wait a few days for LittlePuppers. As for the new template doc it looks fine by me. I may make changes and additions later. I may not have a lot of time the next few days. --Timeshifter (talk) 02:42, 11 March 2024 (UTC)
I don't have an issue with going live with the Android issue and don't feel additional Android tests are needed. I'm just indicating I'm ready, but look it over one last time to make sure because tables are going to have to be manually changed after going live. If a class name changes after going live, then it's more work. If everyone is comfortable that this is more functional and easy for editors to use, then I may go live tomorrow or the day after. Jroberson108 (talk) 04:00, 11 March 2024 (UTC)
Timeshifter, I just got back in town after being away for the past week and a bit so I don't have the time to look at this right now. Ping me again in a couple days if you still need me to look at something. LittlePuppers (talk) 01:13, 11 March 2024 (UTC)
I'm not sure where to put this because of how long this thread is, but both styles look the same to me under the sortable section on my iPhone 14 Plus. You should also be able to simulate screen sizes under Firefox. Aaron Liu (talk) 12:36, 17 March 2024 (UTC)
Thanks Aaron Liu, but sandboxes 243 and 244 are now using the same CSS styles since the new styles went live on March 12, 2024.
In the last day or so, I've been losing the vertical scroll bar when I'm editing articles. I'm using Firefox version 123.0.1 on Windows 10. It only happens when I'm editing articles. For example, it's fine while I'm typing this message. It's not that I lose the entire window: If I make a change in the edit window, then press tab, the cursor moves to the edit summary window, even though the scroll bar has gone. It's not just the scroll bar - I can't page up or page down either. Any ideas? Thank you. 76.14.122.5 (talk) 17:43, 17 March 2024 (UTC)
The Tab key is supposed to take you to the edit summary box. That is how HTML forms operate: the tab key moves to the next focusable object in the form. --Redrose64 🌹 (talk) 23:14, 17 March 2024 (UTC)
Sounds like something is setting overflow-y of <body> to hidden. Try turning off extensions if you have any. Nardog (talk) 00:32, 18 March 2024 (UTC)
Thanks! I'll try to figure that out. I have a bunch of extensions installed, so finding out the culprit may take time. Maybe one was silently updated in the past couple of days and broke something. Thanks for the hint! --76.14.122.5 (talk) 04:06, 18 March 2024 (UTC)
What if we had an AI to suggest edits along the lines of edits typically made by good editors?
What if, for example, an AI could look at the last few-thousand non-reverted mainspace edits made by the top several hundred editors across several sets of metrics (most good articles, most edits, most thanked for edits), and then look at the whole rest of the corpus and find and suggest fixes for standing issues similar to things that were fixed in other articles by the good editors? I have a hunch that an AI doing that would suggest a lot of good basic spelling, punctuation, grammar, and style fixes. BD2412T02:36, 18 March 2024 (UTC)
I'd hope that 'good editors' make their edits on the basis of actually understanding what they are doing. LLMs don't have the capacity for that. If they did, we could get them to write the articles for us, and we could all retire... AndyTheGrump (talk) 04:10, 18 March 2024 (UTC)
Sounds similar to the scripts that some already use to trace the basic and simple edits. I am not sure AI would help with more advanced edits that require remotely understanding the text, as AndyTheGrump notes, although I would be interested in the results it suggests out of pure curiosity. Do people usually give thanks for spelling, punctuation, grammar, and style fixes? CMD (talk) 04:25, 18 March 2024 (UTC)
I do for edits to articles I've created (and I know of other editors who do this). I also might thank a user for an edit of this type that is particularly astute. I've been thanked a few times for reverting vandalism as well. I wouldn't support using AI for this sort of thing though ... there's way too much scope for false positives. If such a project was to be undertaken, each edit should be carefully reviewed by an established editor. Graham87 (talk) 06:35, 18 March 2024 (UTC)
I use semi-automated processes (not AI) to suggest (not make) gnome edits. One of my activities is to spot links which are incongruous and might be intended for a different topic with a similar title, assess them manually, and fix if appropriate. For example, if an article links to Apple but is about iPhones rather than fruit, it might benefit from a piped link to Apple Inc. instead. AI might be able to trawl our articles for similar cases and bring them to our attention for human triage. I expect that AI might be helpful with other types of error too, the key feature being that they follow a pattern but are hard to find with existing tools. Certes (talk) 14:48, 18 March 2024 (UTC)
My understanding is that there are existing spell, grammar, and style checkers that have long used AI models. If someone builds a tool trained on Wikipedia edits, I'm sure there will be editors interested in testing it. isaacl (talk) 06:50, 18 March 2024 (UTC)
There's a lot of hyperbole out there. We (TINW) have been slinging around the term AI for half a century, but despite getting some extremely useful tools, we aren't there yet, and sometimes the results, including grammar and spell checking, look like artificial stupidity. Use only for suggestions and apply sanity checks. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:43, 18 March 2024 (UTC)
Tech News: 2024-12
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
The notice "Language links are at the top of the page" that appears in the Vector 2022 skin main menu has been removed now that users have learned the new location of the Language switcher. [19]
IP info feature displays data from Spur, an IP addresses database. Previously, the only data source for this feature was MaxMind. Now, IP info is more useful for patrollers. [20]
The Toolforge Grid Engine services have been shut down after the final migration process from Grid Engine to Kubernetes. [21][22][23]
RevisionSlider is an interface to interactively browse a page's history. Users in right-to-left languages reported RevisionSlider reacting wrong to mouse clicks. This should be fixed now. [25]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 19 March. It will be on non-Wikipedia wikis and some Wikipedias from 20 March. It will be on all wikis from 21 March (calendar). [26][27]
All wikis will be read-only for a few minutes on March 20. This is planned at 14:00 UTC. [28][29]
I see below every page (up the last hr line) a blank space like three or maybe four blank lines. I don't know why. I'm using the old Vector interface. This happens only here in en.wiki. --ZandDev (msg) 21:56, 16 March 2024 (UTC)
@PrimeHunter: Yes this happen also if I'm logged out (so with the new Vector interface) and with safemode=1 (I had already tried that before) and also with Firefox instead of Chrome. But now I noticed that if I pin the floating index to the side the empty space at the bottom will be reduced. — ZandDev17:39, 18 March 2024 (UTC)
I tried to apply {{prod}} to an article using the visual editor and I got a warning saying that I had to substitute the template. But I could see no obvious way to do this with the visual editor. — Martin (MSGJ · talk) 09:05, 19 March 2024 (UTC)
Thanks I'll give that a go. Would be nice if there was a tickbox or something to substitute a template, or if that could be set as the default for templates like this — Martin (MSGJ · talk) 09:51, 19 March 2024 (UTC)
Once again, I've come across a situation where the changeover of a category from "manually coded navseason and categories" to "preformatted template that autogenerates everything" broke categorization because of a difference between the demonym our category is actually located at and the demonym autogenerated by the template.
The category was Category:20th-century Kyrgyzstani educators, and the act of switching it over from {{Navseasoncats}} to {{Educators by nationality and century category header}} caused the categories for Category:20th-century Kyrgyzstani people and Category:Kyrgyzstani educators to get replaced with nonexistent redlinks at "Kyrgyz" instead of "Kyrgyzstani". I brought a similar case to VPT last year when the same thing happened to a Tajik/Tajikistani category — and as I said that time, I don't have the depth of knowledge necessary to know whether the categories should be at Kyrgyz or Kyrgystani, but either way it is necessary that whichever form they're at the template uses the form they're at rather than generating redlinks for the opposite.
For the moment I've had to work around the problem by wrapping the template in {{suppress categories}} and manually readding the category declarations that were on it before the switchover, but that virtually defeats the entire purpose of the switchover — so could somebody look into how to resolve this? Bearcat (talk) 15:57, 13 March 2024 (UTC)
It's not an error on Smasongarrison's part. It was a perfectly reasonable edit where they did the right thing and it had unintended side effects not caused by them, not a mistake they made that discussing with them would solve. Bearcat (talk) 20:22, 13 March 2024 (UTC)
Thanks for your diligent gnoming, but sometimes getting the problem fixed is better than working around it. That editor created the template in question and added it to the category page, so their talk page or the template's talk page seem like good places to start. Coming here to "Once again..." at VPT every time someone inadvertently links to a red category might not be the best way to resolve problems. Shit happens. I have fixed this problem by tracking down the problem to Module:Find demonym. I have edited the module; see my edit summary for details. If other pages or categories were depending on "Kyrgyz" to be output from that module, they may malfunction, but the module is currently consistent with the vast majority of relevant category names and with Module:CountryAdjectiveDemonym/Adjectives. – Jonesey95 (talk) 21:19, 13 March 2024 (UTC)
I'm glad to hear that this was resolved. And, now I know that find demonym exists, so that's exciting! I can definitely build in a check to see if the demonym breaks. Mason (talk) 21:37, 13 March 2024 (UTC)
Certainly is an error on Smasongarrison's part. Although the change seemed reasonable, it needed much fuller testing, and the related modules to be fixed. This is a change management problem and templates and modules need a lot more care in implementing changes. Graeme Bartlett (talk) 22:21, 13 March 2024 (UTC)
If you don't know what to do, leave it for others to fix it. Using hacks such as suppress categories just hides the problem and does not fix anything. Gonnym (talk) 21:41, 13 March 2024 (UTC)
It's neither my job nor my responsibility to do nothing. Every time Special:WantedCategories updates with new redlinks, every single category on it has to be created or wiped out immediately, with no "do nothing" exceptions for any reason ever, because the list has to be cleared to absolute zero before the next time it updates. The report has a hard numeric limit beyond which it cannot detect additional redlinks at all, so there cannot be any do-nothings that don't get fixed and carry over from one report to another, because every one of those that fails to get resolved pushes the list closer to that cap — so the list getting cleared to zero each time it runs is mandatory and non-negotiable, and I will take no lectures or clapback from anybody about it. Bearcat (talk) 22:41, 13 March 2024 (UTC)
"Immediately"? It looks like the page was last updated more than 17 hours ago, so presumably we have at least that long to resolve problems. Also, it looks like the numeric limit is 5,000 links, and there are 138 links on the most recent report, so claiming that every single entry, without exception, needs to be removed before the next update also seems hyperbolic. Exaggeration and hyperbole might do well to be replaced by a bit of AGF, discussion, and patience. Maybe there is something I do not understand, but that's how it looks from here. – Jonesey95 (talk) 23:02, 13 March 2024 (UTC)
If I leave behind one now, then I'm automatically surrendering any argument that there's any need to clear even one of the other 137 anymore — if I give one redlinked category any special dispensation to stick around unresolved because reasons, then I have to let them all stick around unresolved because why should they be treated any differently than the one I'm not dealing with? Plus, 138 is lower than usual for that report — 200 is more normal, and even then it's only that low because most established editors know that redlinked categories are verboten, and would be a lot higher than that otherwise. So if I don't deal with 138 categories now, then it's 338 by Saturday, and 538 by next Tuesday. And then word gets out that redlinked categories are fine and dandy now, so their use explodes so that there are 2,000 redlinked categories to deal with by next Friday, 4,000 by the Monday after that, and the 5,000 limit has been hit by Easter Weekend. That's why the fact that there is a limit always has to be taken into account regardless of how far away from it any one particular generation of the report may seem to be — because if redlinked categories aren't dealt with right away, the problem doesn't just slowly grow at a rate of only 130 categories every three days: it goes supernova the moment word gets out that redlinked categories aren't considered a problem anymore, and the limit thus gets hit within two to three weeks at most. Bearcat (talk) 00:04, 14 March 2024 (UTC)
Aside from the fact that there are two permanent residents on that category report, negating your entire thesis, that kind of slippery-slope, catastrophic, Manichaean thinking is simply not necessary. We have WP:CATREDLINK, a guideline that explains that an article should never be left with a non-existent (redlinked) category on it, so nobody should reasonably conclude that the existence of one or two red-linked categories on a report for two or three days will inevitably lead to human sacrifice, dogs and cats living together, mass hysteria. For word to get out that red-linked categories were suddenly acceptable, the guideline would have to change, which is unlikely. In general, it's better to resolve problems properly than to work around them and possibly sweep them under the rug. It can sometimes take a few hours or days to resolve problems properly, as it did in this case. That's OK. – Jonesey95 (talk) 01:56, 14 March 2024 (UTC)
Would it be possible to fix another case, while I'm here @Jonesey95? Would it be possible to add Korean as an option? I'd like to be able to use variants of these templates on categories like: Category:20th-century Korean physicians, but right now, Korean doesn't come up. It doesn't red link, but it just doesn't output a nationality at all. Mason (talk) 19:37, 15 March 2024 (UTC)
The only thing that ever counts as any sort of "resolution" of a redlinked category problem is a full solution that makes the redlink go away entirely, and the problem is in no way resolved by anything short of the redlink going away entirely. Either I make the redlink go away or VPT fixes whatever technical problem is causing an autogenerated redlinked category, because if the redlink doesn't go away then the problem hasn't been resolved, and nobody gets to dictate that I have to leave redlinked category problems sitting unresolved. The existence of two isolated "joke" userspace categories that people have tried to get deleted at CFD in the past, and failed to get any sort of consensus that they were actually as problematic as redlinked mainspace categories are, is not counterevidence against the serious problems caused by redlinked mainspace categories, and a redlinked mainspace category hasn't been "resolved" in any way until it goes away. Bearcat (talk) 01:18, 17 March 2024 (UTC)
Wow ... I hope Enterprisey has a backup plan in the works. You never know what you'll miss until it isn't available anymore. — Maile (talk) 02:15, 19 March 2024 (UTC)
@Maile66, Enterpriset The tool itself was moved over to Kubernetes a couple of months ago. However, it looks like there was an issue on toolforge's end with moving the python interpreter over when they shut down grid engine. taavi is implementing a fix, but at some point the tool will need to move over to uWSGI or a custom build container. --Ahecht (TALK PAGE) 21:33, 19 March 2024 (UTC)
Ahecht, I was unaware GUS2Wiki output was actively being used for anything. The script didn't run for a while and I recently ran it again. The ,8 is caused by phab:T313336. It used to be 2300 which GUS2Wiki removes, but somebody changed the namespace number so I'll have to adjust it as well. — Alexis Jazz (talk or ping me) 21:51, 19 March 2024 (UTC)
On Wikipedia, it'd be great if an alias for the template: namespace was created, such as how wp: is an alias to theWikipedia: namespace, which would allow for faster searching of templates in the search bar.
For that, I would propose eithertp:, or t:. Please state which you prefer below, so I can add a task in phabricator! Cheers, Cocobb8 (💬 talk • ✏️ contribs) 12:19, 14 March 2024 (UTC)
While these sort of things COULD happen technically (assuming the value is not in collision) - it very much likely won't be. For one: why? Templates are already directly short-cutted to via {{}}. — xaosfluxTalk14:15, 14 March 2024 (UTC)
The advantage of a namespace shortcut is that I don't have to type Template:… in the searchbox when I want to visit a template to read its documentation, which I do a lot. -- Michael Bednarek (talk) 14:32, 14 March 2024 (UTC)
@Xaosflux, @Michael Bednarek: Yeah, that's what I was getting at: when editing you for sure can use {{}}, but for looking up the template docs in the search bar typing in template: eats some time, which is where tp: could be handy. Cocobb8 (💬 talk • ✏️ contribs) 14:56, 14 March 2024 (UTC)
I did some debugging on the script, and it's now working better in Vector 2022 and Minerva. It should also work on most older skins, including Monobook, Modern, and CologneBlue. --Ahecht (TALK PAGE) 17:56, 14 March 2024 (UTC)
Installed, works nicely on Vector 2022! There is a very minor issue that when shift is still held when typing in {{, the field will stay 1 second on Template: and then go back to {{. It will however go back to Template: once the shift key is released. Cocobb8 (💬 talk • ✏️ contribs) 18:01, 14 March 2024 (UTC)
While Ahecht's script works in the on-Wiki search box, that workaround for the lack of a system shortcut is not a complete solution. It still leaves edit summaries and custom search boxes in browsers unsolved. -- Michael Bednarek (talk) 00:00, 16 March 2024 (UTC)
Also, this isn't really a technical challenge - it is possible and some projects have done it (e.g. ganwiki who even changed alphabets and made T:-->模板: in phab:T355854). You would need to make a proposal, have it well advertised and well attended, and gain community consensus for the change. — xaosfluxTalk15:26, 14 March 2024 (UTC)
User:Cocobb8, I like your proposal, but it's not an RfC and thus an informal discussion. It will have a better chance of being implemented if was a formal RfC. Follow the instructions at WP:RFC for converting your proposal into an RfC. Xaosflux also said this above. -- GreenC14:58, 16 March 2024 (UTC)
@Cocobb8: I would like to point out that it.wiki has already implemented this (with t:). I was astonished when I found out that en.wiki does not have this handy functionality. -- ZandDev13:57, 20 March 2024 (UTC)
Android app cache
Edited pages do not update within the app, but they update when viewed in an Android browser. I tried clearing the app cache. 3MRB1 (talk) 04:18, 20 March 2024 (UTC)
@3MRB1 I strongly advice you do not use android app, they were poorly written by WMF engineers, without enough testing. Anyway, I didn't find an edit from you just before 04:18, 20 March 2024. -Lemonaka08:47, 20 March 2024 (UTC)
Can you please not throw FUD around ? They work just fine within the stated limits of functionality that they provide, you just don't like them. —TheDJ (talk • contribs) 09:42, 20 March 2024 (UTC)
@3MRB1 so you started an edit in the app, saved, and then the page in the app did not show the new version ? Does it do this consistently ? And is it for all articles or was it specific to one article ? —TheDJ (talk • contribs) 09:44, 20 March 2024 (UTC)
@User:TheDJ : Gridiron Club edits from oldid=1214459798 to oldid=1214628526 did not show, after save, in the new version. Now they do show the new version. This has happened before with other pages. I did a lot of small changes from oldid=1214459798 to oldid=1214628526. I think it may have stopped updating after the first few. 3MRB1 (talk) 21:49, 20 March 2024 (UTC)
Pencil button fails on this page. I had to edit the whole page instead of a section or making a new section. 3MRB1 (talk) 22:04, 20 March 2024 (UTC)
Page view numbers: categorising articles
If you have the average number of page views for an article, how can you discover where that fits in the spectrum of views that different articles have? I am looking at one with an average of 919 views per day over the past 30 days[30]. Guessing at some "big hitters", Taylor Swift has 71,811 per day, World War II 27,762, etc. Obviously there are plenty of articles with a lot less traffic – but getting an overall impression of the statistical distribution is not easy. Has there ever been an attempt to display this sort of information: something like a tabulation of number of articles banded into different ranges of page views? Or perhaps a graph? ThoughtIdRetired (talk) 09:38, 20 March 2024 (UTC)
Hello, I came up with an idea, a person will definitely speak some unique words of their own, and everyone's wording habits will also be different. If these are put into the language processing model, we can better identify some sock masters who evaded inspection by forging IP/UA, using forged MAC and free email addresses.
We used to compare these users by ourselves, however, Artificial intelligence is far better than humans in this regard. They can create wording fingerprint for comparison. Yep, I mean that we may create a model based on voice, tense and wordings. Some grammatical errors can also help us to investigate connections among accounts.
Here's some technical barriers, for example, how to get all the contributions from a user by Api? Which model should be used?
And also, some policy barriers, for example, who can use such tools? How to avoid abusing such tools if they are easily got? -Lemonaka08:45, 20 March 2024 (UTC)
Lemonaka, I wonder if this causes any legal concerns. I'm unsure if this would be considered "personal data" under the GDPR. It's an eternal cat-and-mouse game though. Bing, say "Hello Wikipedia, how do I edit an article?" the way Sherlock Holmes would have said it.
“
Certainly, my dear friend. Allow me to channel the great detective, Sherlock Holmes, as I utter these words: “Ah, Wikipedia, my dear fellow, pray enlighten me on the arcane art of editing an article. The game is afoot!” 🕵️♂️🔍
Can someone tell me if Citoid is having issues, I'm getting errors when trying to make refs
Hi all
Today I tried to make refs from NPR and New York Times and both of them failed, I know I've cited these sources before which suggests there's an issue. Is there any way someone can test if Citoid isn't working properly, and/or report this as a bug? Here are the failed refs (I tried them several times)
Citoid uses zotero under the hood. Querying zotero directly (using zbib.org) gives result for both urls, but Citoid fails. So, it is not even an upstream issue. Just file a bug on phabricator, there is not much that can be said about this. Snævar (talk) 20:14, 21 March 2024 (UTC)
Problems with Twinkle
I am trying to rollback some vandalism using Twinkle, but if I click ok "rollback" or "vandalism" it doesn't do anything, instead of reverting the edit and opening the user's talk page, and sometimes the words "rollback", "vandalism" to click don't even appear. Any ideas? Thank you so much 14 novembre (talk) 15:44, 20 March 2024 14 novembre (talk) 09:47, 21 March 2024 (UTC)
1) I am using TwinkleMobile, when I use the full version the problems don't exist
2) Yes, the issues actually started roughly a couple of days ago, so the start problems may easily coincide with the installation of RedWarn and Lupin's tool.
It looks OK to me now. Do you remember the text of any of the messages? This problem is usually caused by a timeout when the page is rendered at a busy time or several complex excerpts are randomly selected simultaneously. The last edit is by me a month ago but was trivial and shouldn't have caused the issue. Pinging DraconicDark who made more substantial improvements and may be interested. Certes (talk) 21:49, 21 March 2024 (UTC)
Hi everyone, I was referred here from Teahouse. I was changing some settings for my account under the appearance section and set my preferred date/time format. All the options are only in a 24 hour format however, and I personally like the 12 hour format. Does wikipedia have an option for this? Special:Preferences#mw-prefsection-renderingHaris00911 (talk) 16:37, 21 March 2024 (UTC)
You might like the Gadget called "Change UTC-based times and dates, such as those used in signatures, to be relative to local time". – Jonesey95 (talk) 23:42, 21 March 2024 (UTC)
Thanks – I always wondered why the same navbox was randomly shown or hidden without any prompting in the wikitext! Is this feature really useful, or just confusing? If I hadn't spotted the pattern after 16 years of editing, perhaps some casual readers haven't either. Certes (talk) 22:39, 21 March 2024 (UTC)
@TheDJ has previously suggested restricting autocollapse to certain types of collapsible content. I'd be generally supportive of restricting it to {{sidebar with collapsible lists}} and {{navbox}} at least as a start, but there may be other templates or places where we've generally treated it as valuable... but someone would have to at least do some thinking about what those might be (Category:Collapse templates might be a good start to review). Izno (talk) 02:13, 22 March 2024 (UTC)
The recent update was undone. Can you confirm that that page was working, in Vector 2022, previously? Also note, it make take a few mins for the undo to take affect. (test link in v22). — xaosfluxTalk20:37, 21 March 2024 (UTC)
Looks like it has to do with the loss of top: auto, as the default .mw-indicator #coordinates includes top: 3.5em. --Ahecht (TALK PAGE) 20:43, 21 March 2024 (UTC)
Yes, that change as implemented by Xaosflux would have caused this issue. The suggested changes if both had been done should not have based on my testing that prompted the edit request. Izno (talk) 02:19, 22 March 2024 (UTC)
That looks like a false positive for this new error, which is supposed to be hidden and not affect signatures, according to WMF staff. I have filed T360797 with a simplified version of your signature illustrating the problem. – Jonesey95 (talk) 16:54, 22 March 2024 (UTC)
@Ianmacm, the short answer is that they want you to specify color:inherit in your signature code wherever you use "background" without a color:
'''''[[User:ianmacm|<span style="background:#88b;color:#cff;font-variant:small-caps">♦Ian<span style="background:#99c;color:inherit">Ma<span style="background:#aad;color:inherit">c</span></span>M♦</span>]] <sup>[[User_talk:ianmacm|(talk to me)]]</sup>'''''
The developers deployed a patch to prevent this new Linter rule from applying to signatures (for now). If you want to future-proof your signature and keep it under 256 characters, this may work:
'''''[[User:ianmacm|<spanstyle="background:#88b;color:#cff;font-variant:small-caps">♦Ian<spanstyle="background:#99c;color:#cff">Ma<spanstyle="background:#aad;color:#cff">c</span></span>M♦</span>]]<sup>[[User_talk:ianmacm|(talk to me)]]</sup>'''''
For any of you who are minimally familiar with how Go modules and packages and their paths are organized and fetched, I could use assistance. It's specifically for Wikipedia. I'm currently trying it locally on Windows command line, but will eventually need to use the SSH on Toolforge.
I'm trying to run a COPY of the this code on my machine. I downloaded "main.go" and tried to run that. I did the standard commands like:
% go mod tidy
% go mod init
% go run .
The problem comes from
import (
"yapperbot-frs/src/frslist"
)
or
% go get yapperbot-frs/src/frslist
I have also tried adding the prefix "github.com/mashedkeyboard/".
but was required as: github.com/mashedkeyboard/yapperbot-frs
Any ideas? Is it a problem with the go.mod on github, or something I should be doing to my local copy to avoid the error?
I'm new to Go, but not to programming.
--David Tornheim (talk) 07:04, 23 March 2024 (UTC)
Not sure if this is it, but in the tried and true method of googling the error (which appears to be 'declares its path', no 'own') I found this:
Thanks. I'll try that. I did find this thread on Google before coming here (to handle a different error report while trying to solve the same problem). Hopefully one of these works. --David Tornheim (talk) 10:33, 23 March 2024 (UTC)
The documentation for GA/Topic says the following: "This template serves as a lookup list for GA topics in templates such as {{Article history}} and {{GA}}."
I want to ask if we can consider coding a JavaScript article wizard in a similar manner we have a JavaScript File Upload Wizard? It would allow for stuff like prefilling of draft pages, etc. AwesomeAasim19:22, 23 March 2024 (UTC)
I'm spitballing here, but we already have something similar in the form of DYK-helper/wizard, perhaps by using {{subst:Biography}} together with adapted source code from the DYK-helper/wizard interface, something similar to what you're describing could be created. — Mugtheboss (talk) 12:12, 24 March 2024 (UTC)
The only editor who has ever replied on that page hasn't edited for three years now. The Haitian Creole community is basically two and a half people. (I'm the half.) WhatamIdoing (talk) 16:38, 21 March 2024 (UTC)
Previewing {{kolektivite tèritoryal}} without parameters produced an image below the infobox heading on ht:Circle, Montana but a broken file link on ht:Circle (Alaska). The cause was that Circle (Q974350) (Alaska) had two images which both had normal rank. I changed one to preferred rank [31] and it works now. The infobox might be recoded to just pick one image if there is no preferred rank but I'm not trying that. PrimeHunter (talk) 20:36, 21 March 2024 (UTC)
I recently added the second image to the Wikidata entry, and the bug was happening before I did that. (I agree that both that I should have specified a preferred rank and that the infobox template needs work.) WhatamIdoing (talk) 22:59, 22 March 2024 (UTC)
@WhatamIdoing: I have changed the preferred rank to the original image as a test [32] and {{kolektivite tèritoryal}} now fails. I guess the problem wasn't having two images but one of the Wikidata fields in the original image. It has three more fields than the new image, and a more complicated name with periods and commas. PrimeHunter (talk) 16:27, 24 March 2024 (UTC)
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
An update was made on March 18th 2024 to how various projects load site, user JavaScript and CSS in Vector 2022 skin. A checklist is provided for site admins to follow.
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 26 March. It will be on non-Wikipedia wikis and some Wikipedias from 27 March. It will be on all wikis from 28 March (calendar). [33][34]
For few days now I've been having trouble with the reply button: after I reply to one comment, the reply button will disappear and I have to reload the page to see it. Quite annoying when I want to leave multiple comments on the same page. This happens in English and Polish Wikipedia, in differne browsers (Chrome and Edge), and in two accounts I checked (I've an authorized alt). Is this a known problem? I am using the modern Vector skin and I haven't changed anything in my prefs/added new scripts/etc. recently AFAIK. Piotr Konieczny aka Prokonsul Piotrus| reply here03:44, 24 March 2024 (UTC)
@piotrus . In this case, I suggest you may have to reset all previous settings in your preference and carefully setup your preference all over again. Secondly, force to stop and clear your browser data and log into your account again. Hopefully this might help. While i don't guarantee that this will work for you, but this steps does solve a lot of browser issues. Goodluck. Thisasia(Talk)11:03, 24 March 2024 (UTC)
I use no skins (duh) and it happens to me too. I wasn't sure if that didn't always happen, but I only noticed it in the past few days as well. – 2804:F1...7E:615D (talk) 07:18, 24 March 2024 (UTC)
Same thing happens to me in Monobook. This is new behaviour; a week or two ago I could use "reply" several times on a page without reloading. —Kusma (talk) 11:37, 24 March 2024 (UTC)
@14 novembre Though this none javascript code of yours aren't necessary, but if you wish to ever leave a none javascript code, then you must stringify and wrap them with the (Template string[``]) ending with a (semi colon [;]), so in your case this is the right way to go about it `{{tls|iusc|User:MPGuy2824/MoveToDraft.js}}.
User:MPGuy2824/MoveToDraft.js`;. Thisasia(Talk)03:21, 26 March 2024 (UTC)
True, but very rarely no? Wouldn't it be better to require some sort of coding/template (like <nowiki>) to prevent the automatic outdenting rather than the other way around? IOHANNVSVERVS (talk) 23:46, 25 March 2024 (UTC)
Talk page discussions - including this one - are performed by abusing HTML definition lists. I don't want to discuss the history of why we do it that way, it goes back more than twenty years and is very complicated. Suffice to say that attempts to change the way that discussions are formatted have frequently failed. --Redrose64 🌹 (talk) 09:42, 26 March 2024 (UTC)
Hi! Posting here in the hope someone with the right editing permissions can fix this, because I don't have an account on translatewiki.net and the user who initially reported this issue said they found that even creating an account didn't give them sufficient editing rights to edit the pages there: The Wikimedia hashtag-#Babel system's messages for Greenlandic are actually Danish: 1, 2, 3, 4, 5, N. Wikipedia's and Wiktionary's native, wiki-internal Babel templates, OTOH, have the relevant Greenlandic text (see wikt:Template:User kl-1, wikt:Template:User kl-2, etc), if someone can copy it over. (I posted about this some years ago and someone fixed kl-0 but not, I now notice, any of the others.) -sche (talk) 02:37, 26 March 2024 (UTC)
None of the linked messages have a history tab so none of them have been created. That means a fallback language is used per mw:Manual:Language#Fallback languages. For Greenlandic the first fallback language is Danish which makes sense. Greenland is an autonomous territory of Denmark and Greenland#Languages says: "The majority of the population speak both Danish and West Greenlandic Kalaallisut (the most populous Eskaleut language). They have been used in public affairs since the establishment of home rule in 1979. In practice, Danish is still widely used in administration, academics, and skilled trades and other professions." Many small languages have translated relatively few MediaWiki messages. It's done by volunteers and is always a work in progress since new interface messages are often added. PrimeHunter (talk) 09:30, 26 March 2024 (UTC)
I would be happy to copy them over to Translatewiki, but I don't know which translations are correct. Even looking at the very first template, they are different on different projects:
I have tried to run both of these citation-fixers several times today and every time I try to run them I get a FAILED An error has occurred. So is it me or is it the system... Shearonink (talk) 13:58, 26 March 2024 (UTC)
hello @Shearonink I'm not very clear about your message but do you mean you are having difficulties with the Auto citation when try to add references? If that's the case, then here is a quick tips on how I usually bypass that.
First use a different browser that is not logged in with your wiki account, run the Auto citation again and after when successful, then comeback to your main browser in which your account is logged in and try again ✅
I'm not sure of the cause of this technical problem, but this usually occur to me when I have used the Auto citation several times. Hence the only option is to try with a different browser that is not log in with your account. If this isn't the problem u are talking about please explain further. Thisasia(Talk)01:53, 27 March 2024 (UTC)
be completely wikilinked or are we OK with the status quo? That's $linkTrail in MessagesEn.php. This has become more obvious since the change of wikilink colors. Ponor (talk) 11:21, 27 March 2024 (UTC)
If you are asking about possibly changing the linktrail rules in MediaWiki then it's not controlled by the English Wikipedia. phab:T47126 has old discussion. If you are asking whether we should write [[bezant|bezantée]] to produce bezantée instead of bezantée (where ée is not link colored) then it isn't mentioned in Wikipedia:Manual of Style/Linking but I would certainly say yes. You can post a suggestion to the talk page if you want a guideline about it. PrimeHunter (talk) 11:41, 27 March 2024 (UTC)
Yes, I am asking about possibly changing the linktrail rule. Help:Link seems to suggest that the first two examples should be completely wikilinked, and they're not.
There was an attempt to fix this, which was reverted here, but things might have changed with the old dependencies by now (and there are other ways to do it anyway).
Help:Link describes Batman's as the right thing, which is a reasonable but debatable opinion. Ignoring WP:OL, Worldschmerz also seems right. as World tells the reader nothing about schmerz (though Weltschmerz does). The others are a bug. The good news is that its ticket's priority was raised to Low ten years ago, so the WMF may find the funding to fix it real soon now. Certes (talk) 11:55, 27 March 2024 (UTC)
@Certes, if [[Batman]]'s produced Batman's at some point, the meaining of "this does the right thing for possessives" might have been different. It, for me, surely looks ugly as Batman's now. Where they mention [[a]]''b'', it's said "this rule also applies", where by "the rule" they mean that the trail should be wikilinked, I believe.
I am not here to discuss the particular examples, I only used the -schmerz example instead of the one generic one in Help:Link. The question is purely technical. Ponor (talk) 12:16, 27 March 2024 (UTC)
Yes, it doesn't say what "the right thing" is other then implying it is however the page looked when the text was written. That may well be with the 's also linked. If so then we should be fixing this globally in MediaWiki rather than by editing all the wikitext to work around a bug. Certes (talk) 12:31, 27 March 2024 (UTC)
The workaround is the solution here because HTML tables don't provide for jump links within the table structure, as far as I know. A link is an inline object, after all. And cells contain inline objects. Stefen Towers among the rest!Gab • Gruntwerk02:42, 26 March 2024 (UTC)
@Uwappa, StefenTower, and DH85868993: PrimeHunter describes the correct technique here. {{Anchor}} just adds extra complexity, and can only be used inside a cell, whereas the id="..." attribute may be used on any of the following: (i) the {| that begins the table; (ii) the |+ that marks a caption; (iii) the |- that marks a new row; (iv) the ! that begins a header cell; (v) the | that begins a data cell. The main difference between the last two and using {{anchor}} is that the former place the id on the cell itself, whereas {{Anchor}} places the id into a span element somewhere inside the cell, not necesarily at the beginning. Therefore, use id="..." in whichever table element is semantically correct, this aids accessibility. --Redrose64 🌹 (talk) 12:52, 26 March 2024 (UTC)
@StefenTower: The five places that I described for placing an id= attribute may also be used for class= and style= attributes. These are among the global attributes that are valid on all HTML elements. I suspect that some of the others, such as dir=, lang= and title=, may also be used in the same positions. I should, at some point, look into carrying out proper tests and writing it up, perhaps in Help:HTML in wikitext. --Redrose64 🌹 (talk) 20:21, 27 March 2024 (UTC)
Today, I discovered Shawnee Park in Louisville had incorrect coordinates in its infobox and WikiData, and so I corrected all that and tried to ensure WikiData for Shawnee Park has the data that its sister flagship parks in the same city, Cherokee Park and Iroquois Park, have. Now, I'm wondering why Shawnee Park won't show its boundaries in red on the map like is done for the other ones. Is there a setting somewhere I'm missing? Stefen Towers among the rest!Gab • Gruntwerk20:50, 25 March 2024 (UTC)
Could we add source tags (independent or not, is it reliable or not, etc) which are starting to be visible in visual editor as an opt in. I think it would help when writing a new draft and doing a self check of its notability, and to assist reviewers in carrying out their reviews (reviewer adds such tags for each source and instructs draft author how to view these tags to aid the new author in understanding which sources are better and which are worse). There could be semi-automated tagger which suggests in edit mode to tag youtube sources as unreliable, for example. Gryllida (talk, e-mail) 00:15, 28 March 2024 (UTC)
@Gryllida I would oppose the "semi-automated tagger" part of this proposal. Whether a source is reliable or not depends upon context, and is often not a binary yes/no question - it is not the case that all YouTube videos are unreliable, for example. If the BBC uploaded an old documentary to YouTube that could be a perfectly reliable source for some information, or it could be hopelessly outdated (and indeed, different parts of the same video could fall into both categories). An interview posted on YouTube could be used in an WP:ABOUTSELF manner, or it could fall afoul of WP:BLP. This kind of thing really needs to be done using editorial judgement. 86.23.109.101 (talk) 13:45, 28 March 2024 (UTC)
"As Session Musician" section for Ry Cooder article is invisible in Safari
I can see it in Firefox. But in Safari, the article ends with that section heading. And if I search for "Hiatt" on the page, it's highlighted in the invisible section, but I still can't see any text. I'm using Safari 17.4 and running Mac OS Sonoma 14.4. I also posted this to the article's Talk page. Peterh6658 (talk) 02:17, 23 March 2024 (UTC)
@Peterh6658: Going to the relevant section in this old version, using Firefox 124, I see that the page is in two columns at that point. The left-hand column has the "Soundtracks" and "As Session Musician" subsections, plus the "Films" and "Written works" sections and the beginning (4 refs) of the "References" section; on the right, we have the remainder of the references, plus the "External links" and navboxes. This two-column layout ends after the navboxes but before the categories box, so something in the MediaWiki software is injecting sufficient </div> tags at that point to finish the page neatly. Viewing the HTML source (Ctrl+U) shows that this is indeed the case: there are <div class="div-col"> tags at each of the four positions that the Wikitext has a {{div col}}, there are </div> tags at each of the two positions that the Wikitext has a {{div col end}}, plus four </div> tags before the category box where I would expect there to be two - one to terminate the last navbox and one to end the page content.
This imbalance was caused by some earlier edits that removed a {{div col end}} from the bottom of the "Soundtracks" subsection and subsequently replaced it with a {{div col}}. This meant that with the {{div col}} being still at the top of the "Soundtracks" section, and another just below the "As Session Musician" subheading, there were then three nested {{div col}}, only one of which was subsequently closed. It could be that Safari doesn't like nesting in this manner; I can't test it, because the most recent version of Safari for Windows (Safari 5.1.7) was way back in May 2012. --Redrose64 🌹 (talk) 16:25, 28 March 2024 (UTC)
Thanks, Redrose64 🌹, for teaching us "Drawling, Stretching, and Fainting in Coils." (reply inspired by the song of the latter's same name by the band Bruford on their first proper album, said song being in turn inspired by you-know-who) Peterh6658 (talk) 17:45, 28 March 2024 (UTC)
@Qwerfjkl try building your query using the guided form here, see if you get the results you expect, and if the string is in the same format. If the string format is different, the documentation may be outdated. If the results are wrong, you can open a bug report on it. — xaosfluxTalk12:52, 29 March 2024 (UTC)
You must be referring to the IPA on the Áed Oirdnide article. After a small bit of messing around, I found that this seems to be an issue with MinervaNeue, as there is no space when I view it in desktop mode (Vector 2022). — Mugtheboss (talk) 12:13, 29 March 2024 (UTC)
More likely, it’s just font specific issue, and it just depends on the character fallback chain that the browser calculates depending on the fonts installed on the device. —TheDJ (talk • contribs) 19:31, 29 March 2024 (UTC)
Mobile site: Clarify "bytes" in page history?
Just encountered this Twitter thread where someone looked at a page history on mobile, and thought that the bytes ± indicator was actually part of an upvote/downvote system. This isn't the first time I've seen someone make this mistake. On desktop, the bytes ± number appears right next to the total bytes and lots of other dense information, which I think makes it clearer that it's not a voting system, but on mobile it's more ambiguous. Perhaps it would make sense to add the word "bytes" on the mobile site? Just a letter "B" could work if "bytes" doesn't fit – not everybody would know what it means, but at least they'd be less likely to think it's a voting score. –IagoQnsi (talk) 21:54, 24 March 2024 (UTC)
Looks like you get the "size-new" if you have "advanced mode" enabled in mobile, and the other if you are not in advanced mode. Both are not very useful for the use case of non-hovered viewing. — xaosfluxTalk17:12, 25 March 2024 (UTC)
I thought that we discouraged this, on several grounds - such as verifiability and the potential for undetected vandalism. --Redrose64 🌹 (talk) 13:49, 30 March 2024 (UTC)
The relevant RfC did not reach a general consensus, but to quote the close there is a consensus on one point: if Wikipedia wants to use data from Wikidata, there needs to be clear assurances on the reliability of this data. I don't think anyone has yet come up with a convincing way to provide that assurance. Mike Christie (talk - contribs - library) 15:14, 30 March 2024 (UTC)
Correction: the reference from Wikidata is being rendered as an error message. Actual data does exist on Wikidata that the template can't render properly. * Pppery *it has begun...23:02, 30 March 2024 (UTC)
I created a redirect page, and a human editor reviewed it. Unfortunately the title was a typo. I moved the redirect to the correctly-spelt title, and User:DannyS712 bot III okayed that.
In my notifications, it then appeared that the human had okayed the new title, and the bot had okayed the old typo one. I don't think this is intended behaviour. For redirects, it might give the impression that an editor has approved a highly inappropriate redirect.
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
Users of the reading accessibility beta feature will notice that the default line height for the standard and large text options has changed. [36]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 2 April. It will be on non-Wikipedia wikis and some Wikipedias from 3 April. It will be on all wikis from 4 April (calendar). [37][38]
Future changes
The Wikimedia Foundation has an annual plan. The annual plan decides what the Wikimedia Foundation will work on. You can now read the draft key results for the Product and Technology department. They are suggestions for what results the Foundation wants from big technical changes from July 2024 to June 2025. You can comment on the talk page.
The buttons of connected gadgets, for example, the wikifier after updating the page are mixed in the middle and back to the right. Where can this be fixed so that the buttons do not move and leave in one place, right or left, please help? In Russian, all the gadget buttons on the left. Here is the screen where I noted these buttons, when they went to the middle. Thank you! Takhirgeran Umar (talk) 22:01, 1 April 2024 (UTC)
It loads ce:MediaWiki:Gadget-AlignTemplateParameters.js by default but hides it in preferences. The gadget adds some buttons to the edit toolbar. Compare [39] to safemode which doesn't have the extra buttons. The position of the buttons vary between page loads for me and you apparently want the position to be fixed. I don't know how to control this. PrimeHunter (talk) 22:59, 1 April 2024 (UTC)
I started typing a reply to a discussion at ANI and a new edit happened so I refreshed to see it (that edit closed the discussion).
The problem now, is that every time I go to ANI it tries to do the "Changes recovered" thing where it scrolls to that topic and says Loading..., and normally would have loaded my reply, but since it's closed it gives up after a bit.
This happens every time I go there now, I have tried starting another reply on another section and cancelling that, but no luck. – 2804:F14:8093:5F01:BD93:DDC2:7C48:C2EC (talk) 01:03, 1 April 2024 (UTC)
You have to temporarily unclose the thread (I usually just comment out the top and bottom templates), this will allow you to close the reply window, and you then revert the changes so the thread is closed again. I ran into this exact problem yesterday and had to temporarily re-open and re-close a thread.[40][41] -- LCU ActivelyDisinterested«@» °∆t°13:50, 2 April 2024 (UTC)
Indented tables
I just realized, that it is possible to indent tables.
This seems like an accidental feature, that could easily be broken with the next CSS change.
But I think it is quite useful on talk pages, and should be kept.
Especially discussions about illustrations become unwieldy, when too many thumbs pile up on the right.
Indenting with colons (ab)uses HTML definition lists, and in HTML, tables may be used inside all three kinds of list - definition, ordered and unordered. It's highly unlikely that the feature will be removed, certainly not with the next CSS change. --Redrose64 🌹 (talk) 14:47, 2 April 2024 (UTC)
@Redrose64 and Izno: It would probably be easy to replicate the indentation with CSS classes. I think it would make sense to combine wikitable mw-collapsible mw-collapsed into something like talktable. The indentation depth could be added with a dash, so the first line would look like {| class="talktable-4". But counting colons is not something people like to do. Would it not be possible to make indented tables official, so that ::::{| would be translated into a table tag with class indented-table-4? — Preceding unsigned comment added by Watchduck (talk • contribs) 23:05, 2 April 2024 (UTC)
No, it's not really reliably possible to do that in the current parser. It may be more possible in the future.
As for the text, there has been discussion about supporting multiline content in lists better already that would involve some new wikitext and would help us support more use cases than just tables. You can look on Phabricator for that if you want. Izno (talk) 00:53, 3 April 2024 (UTC)
@TonyTheTiger: Many of the cells are missing quotation marks in style="...". {{CollegePrimaryStyle|Illinois Fighting Illini}} produces background-color:#13294B;color:#FF5F05;box-shadow: inset 2px 2px 0 #FF5F05, inset -2px -2px 0 #FF5F05;. Without quotation marks, only some of it is included in the style. The documentation at {{CollegePrimaryStyle}} should probably be updated to say that if it's assigned directly to style= in a cell then use quotation marks. The documentation seems to currently assume it's used as a parameter in a template which adds quotation marks. PrimeHunter (talk) 19:14, 29 March 2024 (UTC)
@TonyTheTiger: To expand on that: style= is a HTML attribute, and attribute values must be quoted unless they consist entirely of the 64 characters A-Z, a-z, 0-9, hyphen-minus and full stop. When you use something like style=background-color:#13294B;color:#FF5F05;box-shadow: inset 2px 2px 0 #FF5F05, inset -2px -2px 0 #FF5F05; this contains several characters which are not among the 64: there are three colons, four hashes, three semicolons, several spaces and a comma. How this is treated will depend upon the browser. Some may reject the whole attribute outright; some will ignore everything after the first 'invalid' character (the first colon), some may ignore the lack of quotes and process the whole value as if it were quoted. --Redrose64 🌹 (talk) 20:39, 29 March 2024 (UTC)
@PrimeHunter and Redrose64:, Neither style=“{{CollegePrimaryStyle|Illinois Fighting Illini}}; width=75” nor style=“{{CollegePrimaryStyle|Illinois Fighting Illini}}"; width=75 seems to be the proper correction for style={{CollegePrimaryStyle|Illinois Fighting Illini}}; width=75 in the Preseason national polls section.-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 21:23, 29 March 2024 (UTC)
Well, no. The first one is invalid because you're trying to put width=75 inside a style= attribute, and it's not valid CSS. The second one is invalid because you've put a semicolon after the closing quote - after the closing quote of an attribute's value, only two characters are valid: (i) a space; (ii) a greater-than character >. --Redrose64 🌹 (talk) 21:57, 29 March 2024 (UTC)
The HTML spec permits the use of either U+0022 QUOTATION MARK (") or U+0027 APOSTROPHE (') as value delimiters; by implication, the “ and ” characters are not delimiters but are treated as part of the value itself. --Redrose64 🌹 (talk) 13:02, 30 March 2024 (UTC)
There are three columns of colour dabs, headed 1, 2 and 3. The first three of the five contrast columns show how each of those relate to one of the others - 1/2 is for colours 1 and 2 in conjunction (either text of colour 1 on a background of colour 2 or text of colour 2 on a background of colour 1); similarly 2/3 is for colours 2 and 3 in conjunction; and 3/1 is for colours 3 and 1 in conjunction. The last two, 1/w and 1/b, are for colour 1 in conjunction with white or black respectively. --Redrose64 🌹 (talk) 18:31, 30 March 2024 (UTC)
Cewbot has decided that there are no vital articles
The bot is removing the "vital article" parameter from every talk page, in alphabetical order. Can someone put it to sleep until its operator can sort it out? Pinging @Kanashimi and MSGJ:, who might know what is going on. ~~ AirshipJungleman29 (talk) 15:19, 2 April 2024 (UTC)
Me neither! I hope you don't mind; I copied it over to ANI for more eyes. etc., as it certainly counts a (hopefully temporary!) 'chronic behavioural problem' :) ——Serial Number 5412915:36, 2 April 2024 (UTC)
ooo... i didn't notice this follow up. I have rollback all the changes up till when the issue started after seeing someone rollbacking the changes one by one in my watchlist, and I thought I would save them the trouble and time spent going through some 1,600 edits. – robertsky (talk) 21:19, 2 April 2024 (UTC)
@Robertsky: About that, now that I'm looking closer, it seems your rollbacks and @Remsense's undos reverted multiple edits at once in various talk pages - only the most recent edit in each talk page appears to have been part of this malfunction (usually 10 bytes changes?).
In general, this is the wrong forum for a bot malfunction. You should post in some order to the operator's talk page, WP:BOTN, and/or one of WP:AN/WP:ANI for the appropriate attention. ANI is most likely to get an immediate block, and you have to notify the operator of the post there regardless. Izno (talk) 21:45, 2 April 2024 (UTC)
Is it possible to format a regular table so that there is a large entry or two on a lower row, the way that tv show episode tables are formatted? —blindlynx22:39, 2 April 2024 (UTC)
@Blindlynx Yes, you can use colspan to specify how many columns a single cell will span:
Introducing Edit Patrol: Assisting Rollbackers on the Wikipedia Android App
The Mobile Apps team has recently released a new feature in the Android app to assist rollbackers in patrolling from their mobile device without leaving the Android app. Edit Patrol is a suggested edit that allows users with rollback rights to view the recent changes feed, with access to undo, rollback, thank, and post talk page messages.
The feature is currently available on Indonesian, French, and Spanish Wikipedia. We hope to make it available to English Wikipedia rollbackers in the coming month, and then to all wikis.
You can learn more about the feature and its development on our project page. Edit Patrol does not intend to replace existing patrolling tools, rather fill some gaps that have been highlighted in the mobile space. Prior to writing a single line of code, the team conducted interviews with patrollers and conducted a comparative review of existing patrolling tools. Throughout development, we have continued to incorporate feedback from members of the community. We prioritized collaboration with communities that have traditionally had difficulty utilizing existing tools, specifically folks using mobile devices.
After initial release, we heard requests to add access to user talk warning templates in the talk page message flow. Users are now able to search and use user talk warning templates as part of the tool. For languages that do not have user warning templates, the team reviewed messages across languages & created 10 example messages that will be preloaded into the app: you can learn more about those messages and leave feedback here.
The feature currently allows users to view the feed of recent edits for only one language wiki at a time (the primary language set in their app), but we are interested to hear if there is a preference from multi-wiki rollbackers to have the ability of patrolling multiple languages in a single feed.
Please check out this presentation with more information, and a demonstration of the feature to learn more. If you have any questions or feedback, we welcome it on the project’s discussion page, or please attend our open demonstration hours for this feature on Google Meet on the 26th of April 2024 at 18 UTC (You can determine the right time in your time zone using a time zone converter tool).
PEIS is becoming an issue for one of our larger articles, Donald Trump. An editor is currently stating because of PEIS we cannot pre-emptively archive sources as prescribed at WP:DEADREF and WP:ARCHIVEEARLY. The current limit is 2MB, and has apparently been set to that for decades. The initial reasoning was to prevent denial-of-service attacks through large complex pages overwhelming MediaWiki. But with the significant change in processing power since that initial limit (and the growing complexity of pages on Wikipedia), it is time to revisit that limit. I'd actually suggest at least doubling it to 4MB, but a higher value may be reasonable because (again) computational power has increased a lot since that initial limit was created. The linked task has been active since 2018 (six years ago). I'm not entirely sure what is needed to change this setting, but if you were waiting for an actual article to hit the limit, we're here. —Locke Cole • t • c17:35, 1 April 2024 (UTC)
FWIW this was also discussed last December; the Phabricator discussion you link above reminds me very much of the one about increasing the Lua memory limit, and I hope he won't mind me saying this, but my suggestion is: ping Tim Starling and/or leave him a talk page message—and if you can identify any other dev who seems to have expertise in this area, ping them too—so he can at least give a second/informed opinion on whether increasing this limit is reasonable. Maybe the answer is no, but maybe the answer is yes, since much has changed since the limit was set 18(?) years ago. -sche (talk) 20:33, 1 April 2024 (UTC)
At the time (18 years ago), long articles about US presidents like George W. Bush took about 30 seconds to parse, and by imposing limits, we were trying to keep user-visible latency down to around that figure. Now today Donald Trump takes 9 seconds to parse, so we can congratulate ourselves for directing some small part of the enormous hardware performance gains to an improvement in user-visible latency. But, you might say, human patience remains the same, so we should increase the limits by a factor of 3 or so, allocating the remaining performance dividend to editors so that they can increase the size and complexity of articles by that amount. However, a cloud on the horizon approaches — Parsoid read views are imminently coming, and Parsoid does Donald Trump in 21 seconds. They have staked their claim on half of the gap between current and historical performance. Wirth's law in our context is the process by which performance improvements are greedily consumed by various stakeholders, all hungry for clock cycles, up to the limit of human tolerance for latency, and you might well complain that editors here are getting the crumbs. Parsoid performance is quite sensitive to the number of tags on the page, and if you were optimising for it, removing unnecessary archive links would be a reasonable step to take. So the limit is still doing its job. -- Tim Starling (talk) 01:20, 2 April 2024 (UTC)
... removing unnecessary archive links would be a reasonable step to take. Archive links aren't what I'd call "unnecessary", especially as they've taken a hammer (disallowed ALL archive links for URLs that are still live) to the situation instead of a scalpel (disallowed archive links for specific sources known to be reliable/persistent).
Regardless, the overarching point is, we have language at WP:CITE that says we should be proactive in archiving sources to prevent links from going stale/dead. All things being equal, around 99.9% of the project follows this guidance and archives are added either automatically or semi-automatically using scripts. What we're running in to here is a technical restriction, however, in WP:PEIS. On an article as critical as one for someone facing numerous legal challenges, being the current party-nominee for a Presidential election, and otherwise being very much in the public eye, it seems like pre-emptively archiving sources would be more desirable, not less so.
So the limit is still doing its job. Forgive me, but the initial reason for this was seemingly related to fears of denial-of-service attacks abusing markup and causing the site to stall or fail completely. Not to force editors to limit what can be done with articles. —Locke Cole • t • c03:05, 2 April 2024 (UTC)
That article needs to do better at WP:SUMMARY given its current size of 425 kb wikitext. Cut the article down by a third to a half of its current size and you won't be running into template expansion issues anymore. Izno (talk) 05:03, 2 April 2024 (UTC)
I agree. An article that is close to hitting the limit is a great candidate for WP:SPINOUTs. Even if we have the technical ability to raise the limit, it may be beneficial to keep it the same, in order to discourage the creation of articles that are too big. –Novem Linguae (talk) 05:16, 2 April 2024 (UTC)
@Izno and Novem Linguae: You'll get no argument from me. My primary concern is going into a US election season with archives banned for a page that is BEGGING to be as verifiable as possible. Sometimes sources are paywalled. Sometimes sources go down temporarily. Sometimes sources move because of a site restructure or an article getting renamed. The list of reasons to have archives available on a page like this is far longer than the list of reasons not to. My goal with this was to find the least disruptive (to the regular editors of Donald Trump to make the page editable and get back to including archive links. If someone thinks they can split it off even more than it already is, be my guest. —Locke Cole • t • c05:27, 2 April 2024 (UTC)
@Locke Cole: Given the Donald Trump article is already split into myriad existing subarticles, so long as the sources used in Donald Trump are the ones used in the relevant main articles (if they're not they can be copied to the main articles), they can be archived at the relevant main articles and so preserved in case they are later needed. CMD (talk) 05:05, 3 April 2024 (UTC)
You're welcome to bring that up at WT:CITE where archiving is prescribed as a way to avoid dead links. I do think it's a bad idea to carve out exceptions like this though, as these archive links are also useful to our readers. Having them absent entirely on some pages creates an inconsistent experience, and again, WP:V is policy and WP:CITE works to standardize how we make our articles verifiable. —Locke Cole • t • c05:17, 3 April 2024 (UTC)
I don't think universal pre-emptive archiving is expected, nor is it exceptional to not have universal archiving. I've even seen mass archiving reverted. CMD (talk) 15:25, 4 April 2024 (UTC)
Completely agree. If you've got to the point of fiddling around with reference templates to try and make you article work, your likely well past the point it's should better summarised or split. -- LCU ActivelyDisinterested«@» °∆t°13:53, 2 April 2024 (UTC)
Worth bearing in mind that the limit here is only partially technical - it also serves to limit articles to a reasonable size. Computers may be able to handle doubling or even quadrupling the limit, but would the articles produced actually end up being readable? If you attempt to print out the current Donald trump article it runs to 26 sides of A4, with 12 pages being the article text, that seems awfully long for what is supposed to be a high level overview of a topic. Would a 50 or 100 page long article actually represent an improvement? 86.23.109.101 (talk) 10:36, 2 April 2024 (UTC)
In that case there should be a limit on article size, not post-expand include size (which in 90% of cases is driven by nested templates-within-templates or modules-within-templates such as {{navbox}} and {{navboxes}}, {{flag}}, {{coord}}, and {{cite web}} (et al.), none of which appreciably increase article size). --Ahecht (TALK PAGE) 18:35, 2 April 2024 (UTC)
It is possible to reduce the limit of how big the article can be - Manual:$wgMaxArticleSize, but that will stop any edits to articles that are bigger than the limit and edits that make the article bigger than the limit. The largest page on the english wikipedia in any namespace is Wikipedia:Arbitration_Committee_Elections_December_2018/Coordination/Mass_message at 3.6 MB, where as the limit is probably 1.5 GB. This limit could be reduced to 4MB, but any reduction beyond that would require splitting the pages first. Snævar (talk) 11:48, 4 April 2024 (UTC)
IMO that's a bad suggestion. We normally avoid using #invoke or other parser functions directly in articles as it makes the wikitext even harder to understand. Anomie⚔16:01, 2 April 2024 (UTC)
(edit conflict) I agree. But it's better than the references not working. The fact that PEIS almost always results in tech hacks that don't even clearly improve parsing time rather than the article getting smaller. It's an interesting question (which Tim Starling (WMF) could possibly answer) whether {{#invoke:cite web|...}} is actually meaningfully faster to parse that {{cite web|...}}. Because it's largely things like that the the PEIS limit is forcing people to do, not split articles. The only exception I can think of to this, where an article was split which probably wouldn't have been otherwise, is List of Ang Probinsyano seasons FKA List of Ang Probinsyano episodes. * Pppery *it has begun...16:10, 2 April 2024 (UTC)
You miss my point. Getting the references to work again by trimming cite templates or using invoke is a waste of time, you can get the references to work again by better summarising the articles or splitting content. The former just leads to more fudges and janky hacks to cram in more minor details, while the latter leads to editors thinking about what should or shouldn't be included in the article. -- LCU ActivelyDisinterested«@» °∆t°15:34, 3 April 2024 (UTC)
It is a suggestion for edge cases of articles like this one. And if you have issues with it in the general, you might review how Module:Sports table is being used. I have seen one complaint of Module:Sports table, but it seems that no-one else has had large issues with it.... Izno (talk) 17:06, 3 April 2024 (UTC)
"Post-expand include size" is not the size of the article. It roughly means the total amount of wikitext generated by templates/modules, with wikitext being sent through a template/module more than once being counted multiple times. Thus, by reducing the number of layers of templates by one, those edits did improve the PEIS. * Pppery *it has begun...16:56, 2 April 2024 (UTC)
Let's be very clear. This discussion is about increasing the PEIS limit and related topics, not about the Donald Trump article. No matter what happens here, any change to the article's current consensus item 25 would need a new consensus at Talk:Donald Trump. The same goes for any talk about splitting or trimming, and there's currently an open discussion about that. Thanks guys. ―Mandruss☎04:39, 3 April 2024 (UTC)
Hello, anybody here who could help with this? I wanted to remedy my mistake (missing }}, but apparantly there is the new link to about.com which I never made. El Csuggested to ask here. Thank you for your time. Lotje (talk) 03:25, 5 April 2024 (UTC)
I restored your edit except for the part removing the }} from note 4, and except that the three about.com refs are still removed. They were added years ago, apparently before the site was blacklisted, and now cannot be added again without requesting at MediaWiki talk:Spam-whitelist that the urls be whitelisted (or by only using the archived links and not the live urls). But I think all three are adequately replaced by other existing references for the same claims. SilverLocust💬04:59, 5 April 2024 (UTC)
Another time lag
Hello, VPT,
There is another time lag going on that is interfering with the work of some bots and database reports I rely on. Is there any way to tell how long this will last? It's at 7:19 hours right now but I know these lags can sometimes last for days. Sorry, I know that this question has been asked before (maybe even by me) but I'm not sure where else to go to for answers since these lags have become so common lately. Thanks for any help you can provide. LizRead!Talk!17:07, 4 April 2024 (UTC)
Perhaps a different kind of time lag on my end. For instance, the very page we are on now, has this message at the top: "Unable to fetch revision data. 3,632 watchers, 15,473 pageviews (30 days) · See full page statistics". — Maile (talk) 13:05, 5 April 2024 (UTC)
I realize that this is Wikipedia, not Wikimedia or Wikitech, but when I try to run queries on Quarry as part of my editing jobs, I get the following message
Wikimedia Cloud Services Error
This web service cannot be reached. Please contact a maintainer of this project.
Maintainers can find troubleshooting instructions from our documentation on Wikitech.
Will this impact this project, too? Or is this an internal problem that just the developers need to worry about? Thanks for any tech help you can provide. LizRead!Talk!23:42, 6 April 2024 (UTC)
Detecting MediaWiki:Recreate-moveddeleted-warn from pywikibot
When I retrieve a page in pywikibot and it doesn't exist, I would like to be able to tell if it previously existed. The bot doesn't have the admin flag, so the only way I can think of to do this is to detect that MediaWiki:Recreate-moveddeleted-warn is displayed to the user. Is there a way to see that this is the case in pywikibot? Or is there another way to see that the page was previously deleted without requiring admin privileges? Mike Christie (talk - contribs - library) 13:01, 7 April 2024 (UTC)
I'm not familiar specifically with pywikibot, but there should be an interface to pull the logs from the api, e.g. [45] for Baroness D’Souza, or [46] for User:Pawangurjarinc. Parse that for type==delete && action!=restore, or type==move && action==move && params.suppressredirect==true. —Cryptic13:42, 7 April 2024 (UTC)
The logs might work -- site.logevents(total=100,logtype = 'delete', start = '20230225114000',namespace=0) returns a generator over pages deleted starting at that timestamp. I don't see a way to filter by name, and I don't want to search the entire deletion log but in some cases I'll know the approximate time of the deletion so that will help. Thanks. Mike Christie (talk - contribs - library) 14:25, 7 April 2024 (UTC)
I don't follow? The generator gives me the pages, so I can get the title from x.page().title(); I just can't send a request to only see logs for a specified page. Or am I missing something? Mike Christie (talk - contribs - library) 14:49, 7 April 2024 (UTC)
The reason I think we should do something like this is to deprecate stuff like the old user page editnotice (which I quickly figured out did not work with user subpages a long time ago (like 4 or 5 years ago), when WP:EDN at the time implied so). I think these editnotices should be something similar to how user CSS, JS, and JSON is handled where only the user and specific other users are able to create and edit them. This is better enforced by an edit filter because a user should be able to create editnotices in their own user space (but not others). I also created a draft message MediaWiki talk:Abusefilter-disallowed-editnotice/sandbox for this same purpose. This only would affect "Page" and "Group" editnotices, not "Protection" or anything similar. AwesomeAasim23:15, 6 April 2024 (UTC)
Retrieval of canonical name for Unicode code points?
@JMF and I were mulling over the fact that every time an editor would like to use the {{Unichar}} template to print a specific Unicode character formatted with its code point and canonical name, we have to also enter the canonical name. Immediately, it's clear we have to pluck an index from a 150k-entry long list if we want to automate that, but it seems possible. Is this ill-advised? Remsense诉18:32, 5 April 2024 (UTC)
My initial thought is that pulling the name from WikiData would avoid duplication of this information on Wikipedia. (It might be nice to have a way to flag when there is an officially acknowledged mistake in the canonical name, but I can't think of a concise way that would be readily understandable to a casual reader.) isaacl (talk) 18:48, 5 April 2024 (UTC)
My first take is that an automated process is likely to be more re;iable then manual entry by an editor. Something like {{Unichar|01A2|lookup=name}} should render as U+01A2ƢLATIN CAPITAL LETTER OI while {{Unichar|01A2|lookup=alias}} should render as U+01A2ƢLATIN CAPITAL LETTER OI. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:02, 5 April 2024 (UTC)
Module:Unicode data can do this already: {{#invoke:unicode data|lookup|name|01A2}} → LATIN CAPITAL LETTER OI. If there's a frontend template that invokes it like that, I don't know what it is offhand. —Cryptic20:26, 5 April 2024 (UTC)
What! I swear I checked. In that case, it's crazy that it's not implemented in the #1 editor template to directly use it. Thank you! Remsense诉20:31, 5 April 2024 (UTC)
which apparently looks like an internal medical system! Purging the page does nothing (and in fact it shows in previous revisions). Also, it seems to not appear in other pages that you would expect like Firefox or Safari (web browser), however at the same time is probably not caused directly by the page itself. - 2001:4453:5D2:6E00:6714:4FAA:820F:4DA9 (talk) 13:59, 8 April 2024 (UTC)
While attempting to view Special:Log/ST47ProxyBot, the page times out with a "Database error", and gives the following error message: To avoid creating high database load, this query was aborted because the duration exceeded the limit. If you are reading many items at once, try doing multiple smaller operations instead.
[247f86cf-0f14-41fd-8158-179e904f9c6d] 2024-04-08 08:03:05: Fatal exception of type "Wikimedia\Rdbms\DBQueryTimeoutError"
Not sure if this is an issue that's just inconvenient or one that could be abused, if the latter, feel free to delete/redact my comment. —Locke Cole • t • c08:23, 8 April 2024 (UTC)
This may be a bug (for users with many logs, Special:Logs always fails) - waiting a bit to see if it clears or if someone has more information. In the meantime @Locke Cole you can view that accounts logs if you specify the log type first (here are the "block" logs) — xaosfluxTalk10:28, 8 April 2024 (UTC)
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
Web browsers can use tools called extensions. There is now a Chrome extension called Citation Needed which you can use to see if an online statement is supported by a Wikipedia article. This is a small experiment to see if Wikipedia can be used this way. Because it is a small experiment, it can only be used in Chrome in English.
A new Edit Recovery feature has been added to all wikis, available as a user preference. Once you enable it, your in-progress edits will be stored in your web browser, and if you accidentally close an editing window or your browser or computer crashes, you will be prompted to recover the unpublished text. Please leave any feedback on the project talk page. This was the #8 wish in the 2023 Community Wishlist Survey.
Readers using the Minerva skin on mobile will notice there has been an improvement in the line height across all typography settings. [49]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 9 April. It will be on non-Wikipedia wikis and some Wikipedias from 10 April. It will be on all wikis from 11 April (calendar). [50][51]
New accounts and logged-out users will get the visual editor as their default editor on mobile. This deployment is made at all wikis except for the English Wikipedia. [52]
Is there any way to get pageviews statistics for a Media Viewer page on Wikipedia?
Hi all
Does anyone know if there is any way to know how many times an image was viewed in Media Viewer? It looks like from the URL that Wikipedia has a separate URL for each location on each language Wikipedia an image is viewed. E.g
Hi TheDJ thanks so much, can you tell me exactly what this is measuring, is it all views of the image on all articles its used on + media viewer or something else? John Cummings (talk) 20:53, 8 April 2024 (UTC)
I have just created this draft, but the image is highly oversized. I have tried both default image size and then 250px manual. What's the problem? Kind regards 14 novembre (talk) 🇮🇹 18:45, 9 April 2024 (UTC)
This is a question about the opening of threads at the Dispute Resolution Noticeboard. In particular, exactly where is the specification that sets the Do Not Archive Until date in a new thread that is opened by what appears to be WP:Dispute resolution noticeboard/request and WP:Dispute resolution noticeboard/Header? It appears that the Do Not Archive date is being set to two weeks after the case opening date. This means that cases that have been open for more than two weeks and have no activity for 48 hours are being archived. I am planning to change the archival parameter so as to wait 72 hours rather than 48 hours, but I would also like to set the Do Not Archive Until date to start out three weeks rather than two weeks after filing. Active cases often do not get resolved in two weeks, and do not always have activity in 48 hours. So can someone please tell me where the Do Not Archive Until date comes from? That is, where is the computation done? Robert McClenon (talk) 18:20, 6 April 2024 (UTC)
Thank you, User:Redrose64. That is interesting and puzzling. Then why was Do Not Archive set to 1 April 2024 in Wikipedia:Dispute_resolution_noticeboard/Archive_244#Climate_change, which appears to have been filed on 18 March 2024? The thread was archived because there was no activity for 48 hours and it was after 1 April, so the bot was honoring the parameters. I will look at the template in more detail in a while, but I am puzzled. I thought that there might be a technical answer. I am still sure that there is a technical answer, but it is even more complicated than I would have thought. Robert McClenon (talk) 19:52, 6 April 2024 (UTC)
If someone used the clickable button at the top of the DRN page to make a request, the report text is defined by the javascript behind it, which has the DNAU set to 14 days. You can see the wikitext it creates at MediaWiki:DRN-wizard.js#L-189. Aidan9382(talk)07:49, 7 April 2024 (UTC)
Thank you, User:Aidan9382. So that is indeed setting the DNAU timestamp to 14 days after filing. Whoever thought that disputes would normally be resolved in two weeks was being very optimistic, maybe because they thought that there would be dozens of volunteers, one working each dispute. How do I request that the 14 be changed to 28? Robert McClenon (talk) 15:16, 8 April 2024 (UTC)
Attempt to edit the Javascript page, see the button that says "submit edit request", click that, then make the request. An interface admin will be along Soonly. Izno (talk) 16:44, 8 April 2024 (UTC)
I'll preface by saying this is minor, since you can just search again without going back.
I am using Google Chrome, desktop, and today I noticed some odd behaviour with search:
I went to Special:Search (technically an archive search, but it is happening with just the base one too);
I typed a search term and successfully searched it;
I clicked back on my browser (it took me to the search page, with the search term I typed in the box - this is expected);
I then cleared the box and typed a new search term and clicked search again;
The term that was searched was the one I had searched the first time around, not the new one I typed in.
So, in short, if I search for something from Special:Search and then navigate back to before that search happened and then try to search for something else, it will always just repeat the first search. – 2804:F14:8090:C501:686B:E2D5:C69E:9592 (talk) 02:07, 8 April 2024 (UTC)
I see the same with with Edge, which is based on Chromium, so it has some commonality with Chrome. I'd guess its browser caching or some cookie wierdness. RudolfRed (talk) 03:21, 8 April 2024 (UTC)
By the way I looked at the inspect element, and it does look like the image shared([53]) in that bug report - in fact, if I go back and try searching and repeat that a few times, there will be a new element for each of my new searches (though it always searches the first one).
When clicking search it calls the setSearchSubmitTrigger function in modules/ext.advancedSearch.init.js;
$searchField is the actual searchbox element you type in, in line 60 that text is processed and saved to a variable, and in the next lines that value is put in a new, hidden, <input> element. This new element is created with a name attribute copied from the searchbox element (this hidden element is the one with name="search" in the image in that bug report);
In line 65 the value of the searchbox's name attribute ("search") is then cleared, the search then proceeds using the hidden element;
The bug then, is that when you navigate back on Chrome (and I guess Firefox), the page doesn't get (down)loaded again (browser cache?). The searchbox and this hidden element are still in the page and in this post-search state.
When you search again, it creates a new hidden element with a name attribute set to an empty string (because it's copying from the searchbox one and that one was cleared). When the search proceeds it then reuses the hidden element that has the name attribute set to "search", which is the one created in the original search.
Don't know if this is quite the correct forum to be posting this: When one views 'edit history' on any given article, selects the different versions, and then clicks on Compare select revisions, the pale yellow used to highlight deleted mark up is barely visible. Esp when only one character in a sentence or paragraph has been deleted, which is virtually impossible to discern sometimes. Is there any way to change the (very) pale yellow used to highlight deleted characters to a more visible tone or color, perhaps orange or gold? — Thanx. -- Gwillhickers (talk) 17:34, 9 April 2024 (UTC)
Table of Contents can't display some statistics symbols
(I'm posting it here since this place gets more traffic than Wikiversity). We have a statistical page in Wikiversity which includes statistical symbols in the headings. While there's no issue with those symbols shown in the body of the page, the Table of Contents is bugged whenever these symbols are used. Does anyone have the solution to this problem? OhanaUnitedTalk page21:16, 10 April 2024 (UTC)
@OhanaUnited: The first problem heading is ==== Haphazard weights with estimated ratio-mean (<math>\hat{\bar{Y}}</math>) - Kish's design effect ==== which contains <math>...</math> markup. The problem that you observe is why our MOS:HEADINGS says For technical reasons, section headings should ... Not contain <math> markup. --Redrose64 🌹 (talk) 22:33, 10 April 2024 (UTC)
Anchor
I am having trouble putting an anchor at a specific row in List of cover versions of Led Zeppelin songs. In particular, I want an anchor on the song "That's the Way". I tried
| rowspan="4" | {{Anchor|"That's the Way"}} "[[That's the Way (Led Zeppelin song)|That's the Way]]"
but loading the page with the anchor in the URL didn't seem to take me there. I looked at the documentation at Help:Tables and locations § Section link or map link to a row anchor which told me to try
|- id="That's the Way"
but I'm getting the same issue (also, I'm not certain how to encode quotation marks if I go the id on the row route). I'm sure I'm missing something obvious here. Kimen8 (talk) 16:31, 10 April 2024 (UTC)
This is what I figured. Something with my browser, even caching, who knows. I tried incognito and it didn't work. Good to know the current version works.
Do you know how to escape quotes using the row id anchor? Or should I just use the anchor template in that situation?
Uwappa and PrimeHunter above are talking about the display of times in the watchlist, page history, and other special pages.
If you're talking about the UTCLiveClock gadget ("(S) Add a clock to the personal toolbar that displays the current time in UTC and provides a link to purge the current page (documentation)"), docs at the top of mw:MediaWiki:Gadget-UTCLiveClock.js specify what to add to your common.js or skin.js to change the timezone.
If you're talking about the timestamps shown on comments in discussion pages like this one, there's a CommentsInLocalTime gadget ("(U) Change UTC-based times and dates, such as those used in signatures, to be relative to local time (documentation)") to adjust the display, but I believe you'll have to live with UTC in the editor like the rest of us around the world do.
I have a script at User:TheTechie/tut.js. The function getText is supposed to return something, but it returns undefined. Even alerting the returned wikitext returns something, but returning it or assigning it to a variable and using it in arcTostill returns undefined.
Browser: Chrome 122.0.6261.137 (either stable or LTS)
Can someone help me here? Thanks --- thetechie@wikimedia: ~/talk/$01:34, 11 April 2024 (UTC)
First off, are you calling getPage from somewhere? I don't see a call to it in the code currently.
Second, have you tried step debugging it in Chrome Dev tools? Press f12, ctrl shift f to search for getpage, place some breakpoints inside by clicking on the line number, then run the code. Hover over variables and hit f10 to see what the code is doing. –Novem Linguae (talk) 02:14, 11 April 2024 (UTC)
@Novem Linguae Sorry, I meant that getText stores value in a variable called wikitext, which when used in arcTo, is equal to undefined. When the wikitext got in getText is alerted, it returns something, but when the wikitext is assigned to a variable and used in arcTo it is undefined. As for the dev tools thing, I'm currently kinda busy and can't use devtools right now, I will when I get the chance. Sorry for the confusion. thetechie@wikimedia: ~/talk/$15:36, 11 April 2024 (UTC)
I installed your script just now and took a closer look. The getText codepath never runs because nothing calls it. Are you saying you need getText to run so you can set the wikitext variable to something other than undefined? If so you need to put getText( title ); somewhere. –Novem Linguae (talk) 16:07, 11 April 2024 (UTC)
Unrelated tip: it's hard for other developers to read your code if you abbreviate. I'd suggest expanding TUT, arc, arch, arcTo, sm, etc. to use their full names. –Novem Linguae (talk) 22:52, 11 April 2024 (UTC)
getText doesn't have a return statement, so it won't return anything. If you want to make it return Promise<string>, it needs return statements on line 16 and line 31. See promise chaining. – SD0001 (talk) 16:20, 11 April 2024 (UTC)
Also I appear to have done something on accident which causes the portlet to not appear, even though the function to add a portlet is called. Any help is appreciated. thetechie@wikimedia: ~/talk/$21:54, 11 April 2024 (UTC)
This week's Article for improvement seems to have gone missing. There was one last week, and there's one scheduled for next week, but there's none for this week:
Can we make AfD notification smart enough to notify the editor who turned an existing redirect into an article, rather than notifying the editor who merely created the redirect?
As a redirect-happy editor, I get these all the time. I make a redirect somewhere because the subject is mentioned, but not independently notable. Some other editor comes along and turns the redirect into an article. A third editor nominated the article for deletion, and who get's the notification? The editor who turned the redirect into an article? No, it's me. How hard is it to make the obvious fix to this? BD2412T23:16, 7 April 2024 (UTC)
@BD2412 can you be more specific about this "notification" you are referring to? echo doesn't have a trigger that fires when someone discusses deleting a page. — xaosfluxTalk23:51, 7 April 2024 (UTC)
@BD2412 thanks. Mediawiki doesn't do this in core, and there are many many ways someone could be notified similar to that. In your specific case you seem to be referring to this edit, and that the editor made (possibly unknowingly) a bad edit - correct? That edit claims that it was made with the help of the PageTriage extension, so you may want to report a bug about it. — xaosfluxTalk00:13, 8 April 2024 (UTC)
@Xaosflux: (do I need to ping you, by the way? Are you watching the discussion already?) The editor didn't make a mistake; the notice is sent automatically from the editor's account when the editor uses certain tools to nominate an article for deletion. BD2412T00:29, 8 April 2024 (UTC)
(yes please use ping I don't use "subscribe" echo notifications) As I noted above, based on the edit tag this user appeared to use an extension to help them make this edit; if this isn't the desired behavior for that extension it can be reported to the extension maintainers using the link I provided above. (Had this been a different tool, such as Twinkle, there would be a different set of volunteers to look in to it). — xaosfluxTalk00:48, 8 April 2024 (UTC)
That happens a lot. And when it is something in software, it needs to be addressed by a limited number of developers for that software (there are currently over 200 open tasks for that extension alone). This is not something that we can fix here on the English Wikipedia. — xaosfluxTalk01:28, 8 April 2024 (UTC)
I have long had a similar annoyance, which I have mostly ignored. As an AFC reviewer, I sometimes move a sandbox draft that has been submitted for review into draft space. This creates a redirect from the sandbox to the draft, and I appear to be the originator of the draft. Either six months later, or much later, I get a notice that "my" draft has been deleted as G13, an expired draft. I think that this is the same issue, in which the creation of a redirect confuses Twinkle. Is this the same issue as User:BD2412 is reporting? Robert McClenon (talk) 15:10, 8 April 2024 (UTC)
Yes, User:Xaosflux, that is what I was describing. If a page that I moved from a sandbox to draft space is ignored for six months, I then get a G13 notice that it was deleted. Yes, I don't consider myself to have been the draft creator, but I do get the notice. No, I do not create the draft by copy-paste. I dislike copy-pastes as much as the admins who have to do history-merge to correct for them. Yes, there is a persistent minor problem with who Twinkle thinks is the author. Robert McClenon (talk) 16:15, 9 April 2024 (UTC)
Yes, I see that this was first reported five years ago. There is a persistent minor problem that has been around for so long that the bug has the status of a naturalized citizen. Robert McClenon (talk) 16:20, 9 April 2024 (UTC)
@Robert McClenon thank you, from your notes above this specific error is only coming from Twinkle, correct? Twinkle issues can generally be addressed on-wiki, it just takes someone to write patch for the script. — xaosfluxTalk17:08, 9 April 2024 (UTC)
I don't believe that any notification is technically required, the obvious fix would be to get rid of notifications... But I don't think thats what you mean. Horse Eye's Back (talk) 15:59, 9 April 2024 (UTC)
Actually, if I am the one who turns a redirect into an article, I would want to be notified if that article is nominated for deletion. BD2412T16:23, 9 April 2024 (UTC)
The watchlist seem to fill that role for most, personally I almost always hit the little star when making a redirect or unredirecting. Horse Eye's Back (talk) 17:00, 9 April 2024 (UTC)
Some editors don't use watchlists, and would still like to be notified that their work is being tagged for deletion. Templates on user talk pages are the "gold standard" for notices to editors, and so are required for noticeboards, where pinging is not a substitute. Some editors may not care about these notifications, but other editors either want them or should receive them, so that editors who do not care for them can ignore them. Editors who receive misdirected notifications, as are being discussed here, sometimes ridicule them. Robert McClenon (talk) 04:34, 10 April 2024 (UTC)
Thank you for mansplaining Templates to me... Including the completely irrelevant information about templates related to noticeboards when we're discussing AfD notification. Next time resist the urge. Horse Eye's Back (talk) 16:17, 12 April 2024 (UTC)
citoid not working for some refs that used to work
Using the search function at the top of the page for a case with a redirect to an anchor brings the reader to the top of the redirected article, not to the anchor, which is not convenient for the reader. Is this behaviour intended? This seems to be a significant down-side of redirect to anchors for me.
The following example is for illustration (the question is not about this specific example): There is a redirect for Facial expression recognition. The search function will show Affective computing as a result. Clicking on it leads to the beginning of this article, which itself does not contain "Facial expression recognition", because the anchor leads to "Facial affect detection". Kallichore (talk) 19:08, 12 April 2024 (UTC)
Upon clicking, I found metadata in Hungarian, which is unusual, as the page is new and not previously associated with Hungarian. Additionally, no image is displayed.
Metadata: Solar eclipse of 2024 April 8
eclipse solar del 8 de abril de 2024; 2024. április 8-i napfogyatkozás; 2024ko apirilaren 8ko eguzki eklipsea; eclipse solar del 8 d'abril de 2024; Sonnenfinsternis...
Could the search feature generate metadata that accurately describes the page's content and include an image from the page? AceSeeker (talk) 23:53, 12 April 2024 (UTC)
When you search for that string on the English Wikipedia, you get reasonable results, as far as I can see. It looks like you did this search on Wikimedia Commons, which is different from the English Wikipedia, and which editors here are not responsible for. It appears that the Commons page that is the first result uses a template called {Wikidata Infobox}. The page description that you are seeing appears to be the names of the corresponding page as listed on Wikidata at d:Q2620078. I don't know why that template on Commons pulls in that data, but you could ask about it at commons:Template talk:Wikidata Infobox. – Jonesey95 (talk) 00:07, 13 April 2024 (UTC)
Thank you for prompt response and clarifying that the issue may be related to the template {Wikidata Infobox} on Wikimedia Commons. I'll follow up on the commons:Template talk:Wikidata Infobox page to address this matter. Appreciate your assistance! AceSeeker (talk) 00:25, 13 April 2024 (UTC)
I opened a phabricator issue about this but then I realised I should have discussed it here first.
So, when using the edit button for the lead section on mobile (I'm on mobile web, I have no idea if the app is different), no section link is included in the edit summary. On the other hand, on desktop when the "Add an [edit] link for the lead section of a page" gadget is used, a section link is correctly added. In my opinion, mobile should be updated to match desktop's behavior. Nickps (talk) 14:09, 13 April 2024 (UTC)
Not sure if this is the right place, newbie editor.
So I was trying to reset the password for my old account, Lovecodeabc, so I requested password resets. However the resetting of passwords did not work, and it seems that if I send a password reset on Special:PasswordReset for my email, it works, but not for my username. Additionally, the temporary password emailed for the Lovecodeabc account does not work. I just want to have the Lovecodeabc username back. Any suggestions? Lovecodeabc(tm) (talk) 14:12, 13 April 2024 (UTC)
The only way to reset a password is by email, and only if you had previously registered and confirmed your email to an account before you forgot the password. Special:PasswordReset always requires both a username and a password, and will only send a reset if both of them match. You can also only do one reset per day in most cases. The first username you mentioned does not appear to have an email registered, unless you specifically reconfigured it to be for reset only and not for wikimail. — xaosfluxTalk14:54, 13 April 2024 (UTC)
Special:PasswordReset only requires one of username and email address. That's why it says "Fill in one of the fields to receive a temporary password via email". User:Lovecodeabc has not specified a valid email address.[55] The message is different if you have a valid address but have chosen to disallow mails from others. @Lovecodeabc(tm): I guess you entered the email address for Lovecodeabc(tm) and the mail says so, not Lovecodeabc. PrimeHunter (talk) 16:30, 13 April 2024 (UTC)
Oops, forgot that Send password reset emails only when both email address and username are provided. is off by default! So yes, it will send you reset links for ALL the accounts you have under an email address - but again if the email address was never confirmed to the account it won't. — xaosfluxTalk16:54, 13 April 2024 (UTC)
@Lovecodeabc(tm): I did a test. "This user has not specified a valid email address." at https://en.wikipedia.org/wiki/Special:EmailUser?wpTarget=Lovecodeabc can both mean the account never saved an email address and never confirmed it (see Help:Email confirmation). A temporary password can be sent to an unconfirmed email address. I don't know why the password didn't work for you. It's also odd that your screenshot says "lovecodeabc" with lowercase "l" (unless it's an uppercase "L" in a weird font). The first character of usernames is automatically capitalized. If you wrote it as "lovecodeabc" when the account was created then I don't know whether the lowercase "l" is stored somewhere and can still be retrieved in some situations. Anyway, the account only has 19 edits and can just be abandoned. Special:Contributions/Lovecodeabc only shows unimportant userspace edits and Special:CentralAuth/Lovecodeabc shows no edits at other wikis. If you really want the username then you could try Wikipedia:Changing username/Usurpations. It's usually only for accounts with no edits but rare exceptions are made. First check several times in different browsers that a temporary password doesn't work. PrimeHunter (talk) 23:41, 13 April 2024 (UTC)
@Suffusion of Yellow: My account is Lovecodeabc, not Iovecodeabc. Sorry for the confusion!
@PrimeHunter: I'll look into Wikipedia:Changing username/Usurpations. I've checked Mozilla Firefox on Ubuntu 22.04 and Safari on iPadOS. Are there any issues with those two browsers? I haven't used Google Chrome to try it yet. (also, isn't Google Chrome based on Chromium/WebKit, same as Safari)?
@Lovecodeabc(tm): Everything technical appears resolved now. Lovecodeabc hasn't stored an email address (or has an unknown and unconfirmed address) so it doesn't work to write Lovecodeabc at Special:PasswordReset. Iovecodeabc has stored an email address so it works to either write Iovecodeabc or the email address, but it only sends a password for Iovecodeabc. https://en.wikipedia.org/wiki/Special:EmailUser?wpTarget=Iovecodeabc indicates the email address is not currently confirmed but that can be done as described at Help:Email confirmation. Zzyzx11 wrote there [56] that you need a confirmed email address to reset your password but an unconfirmed stored address is apparently enough for that. Confirmation is required for other email features. PrimeHunter (talk) 02:27, 14 April 2024 (UTC)
Hello guys, it's been a few hours and I can't edit any page on Wikipedia not even my userspace. Prior to this, for about 30 mins I had an issue checking the page history revisions of a particular page. While checking the page history, it seemed to glitch with an error saying "Unable to stash Parsoid HTML." I couldn't compare the revisions of other editors. Normally I'd ignore such issues thinking something related to "Wiki Sever" is going on, but now it's getting me worried. Rejoy2003(talk) 14:11, 14 April 2024 (UTC)
I'm also getting ""Unable to stash Parsoid HTML" on Chrome on Windows 11. Same thing on Firefox on Windows 11. Looks like Microsoft Edge on Windows 11 works properly.
Okay I can edit now, but still there's still minor glitch or bug (along with the Parsoid HTML pop-up) while checking some history of some pages. I tried to login into my account through Opera browser, the good thing is I can edit back. Probably something's up with Google chrome or Firefox. Rejoy2003(talk) 14:45, 14 April 2024 (UTC)
I'm also getting the same error message saying, "Unable to stash Parsoid HTML". But what's weird is I tried using the Legacy renderer instead of the Parsoid; But it still says: "Unable to stash Parsoid HTML". I don't understand how come a problem with the new Parsoid renderer, could be effecting the Legacy renderer also. 𝓥𝓮𝓼𝓽𝓻𝓲𝓪𝓷24𝓑𝓲𝓸 (ᴛᴀʟᴋ) 15:20, 14 April 2024 (UTC)
Changing "input element" to "anchor element" and then making anchor elements unselectable
Hi, after the title of articles, and after final rendering, an expression appears as
"translate links from en to fa". Bug scenario is that when we want to select the title, if we suddenly extend the selected region, for example for Wikipedia article, the texts of "Toggle the table of contents" and "en" and "fa" would be in our clipboard. So after pasting the clipboard, the total clipboard text would be:
Toggle the table of contents
Wikipedia
en
fa
To solve this problem, we should apply these styles:
.vector-page-titlebar-toc.translator-equ-wrapper{-webkit-user-select:none;/* Safari */-ms-user-select:none;/* IE 10 and IE 11 */user-select:none;/* Standard syntax */}
But the element type for "en" and "fa" is "input" and we can not make "input elements" unselectable, so please convert "input element" to "anchor element" for "en" and "fa" and then apply the above styles. Thanks, Hooman Mallahzadeh (talk) 16:46, 13 April 2024 (UTC)
Hooman Mallahzadeh: This was proposed here User talk:Ebrahim/ArticleTranslator.js#user-select but was making breakage in some other browser so I applied another solution which supposed to not have the issue which apparently isn't imperfect in your case though I couldn't reproduce your issue. Guess the best way forward is to add your username to a blacklist for the tool so you can develop your own version and after that if your version covers all the use cases on all the different browsers we can merge the versions. Does that sound good? Just please keep your changes to minimum possible for the ease merging back the versions. Thanks −ebrahimtalk06:27, 14 April 2024 (UTC)
Ok, I can reproduce this, it only happens on double clicks (and not in triple clicks?), and only happens in Chrome and not in Safari and Firefox. Changing those input elements to editable anchor elements isn't that easy, in fact it initially was like that before this edit and some users weren't able to edit them when needed and having that with user-select: none makes users not able to select the text inside to modify the actual language code. −ebrahimtalk06:56, 14 April 2024 (UTC)
@Ebrahim No the problem is not resolved! To correct that, at this page and at the lines 340 and 341, you should convert input element to anchor element like this:
Regarding the user script (not toggle part), unfortunately that solution will disturb the tool on other browsers and things like this can happen on double/triple clicks on Safari (at least it once it used to be). I'm testing with all three browsers (Chrome, Firefox and Safari) but suggestions that have given to me were fixing one browser issue making the other major browsers worse so maybe I can add you to the blocklist of the tool so you copy the script and use your version, then if your solution could work on other browsers on my testing I can apply it to the main script also. −ebrahimtalk09:23, 14 April 2024 (UTC)
@Ebrahim Such problems (inconsistencies between browsers) arise from bad design of codes. Maybe you should refactor this Javascript code. Implementing codes layer by layer such that one layer be completely independent of other layers would probably solve this bug and other similar bugs. Hooman Mallahzadeh (talk) 09:49, 14 April 2024 (UTC)
Hi there, I started having this issue today that's making it nearly impossible to edit.
When I click "review your changes" after editing a page, "template parameters changed" appears for EVERY template on the page, even if I have not changed any of them. Here is a screenshot I took (uploaded to Imgur). I tried disabling all my user scripts, and I am still having the issue.
I am using Firefox version 124.0.2, on desktop, and my browser is up to date.
Hey all, I've left the results of the investigation in the phab task, but this is a one-off disruption because of changes in contents of data-mw attributes of template content wrappers in Parsoid HTML. When cached HTML (generated by older production code) is compared with new HTML (generated by new production code that went out this week), you will see these noisy diffs reported by the visual diff code which compares HTML (not wikitext). But, you shouldn't run into this in subsequent edits. Sorry about the disruption. SSastry (WMF) (talk) 13:43, 12 April 2024 (UTC)
@SSastry (WMF): Thanks for the explanation. I thought page diffs are based on Wikitext. Can you explain why in this case it is comparing the output HTML instead of the Wikitext? RudolfRed (talk) 19:54, 12 April 2024 (UTC)
Thanks so much for your quick fix on this and the reply, I really really appreciate the work y'all do on this site! I've still been having this issue a few times today but I assume that's just because of the cached stuff, and it'll fix itself? (Sorry, I don't know much about caches and HTML and such.)
Sorry to reply again, but I'm still getting the error often. Do I need to clear my cache or something? Again, sorry, I'm not super knowledgeable on this stuff. Thank you! HeyElliott (talk) 03:20, 13 April 2024 (UTC)
You don't need to do anything on your end. If the page is edited across the deployment date, that first edit will have this problem in visual diffs. You could forcibly clear the cache of the page via the purge query parameter if you wish and then look at the visual diff again - that should fix the problem in most cases. SSastry (WMF) (talk) 09:29, 15 April 2024 (UTC)
I discovered recently that floating tables is disabled in mobile using !important in the CSS. So those two tables are arranged vertically in mobile view, despite being so narrow. I discovered this when trying to make a template more responsive. — Jts1882 | talk12:50, 15 April 2024 (UTC)
Hmm, weird. Yes, tables arranged vertically even if plenty of horizontal space available.
I believe that File:2024 Total Solar Eclipse (NHQ202404080102).jpg taken by NASA photographer is superior to the image now in the infobox of the article. In particular, it shows the Solar prominences much more clearly. However, I cannot figure out how to replace the image in this particular infobox. By the way, the photo was taken in Dallas, not in Indianapolis where the current image was taken. Any assistance would be appreciated. Thanks. Cullen328 (talk) 00:11, 15 April 2024 (UTC)
I have no idea why it has to be so complicated. LOL. Complexity is the enemy that looks like a friend. -- GreenC18:05, 15 April 2024 (UTC)
@Cullen328 I'm oppose this change because the image you're proposing has noticeable noise around the corona. In addition, there is already an image of the solar eclipse in Dallas, Texas in the gallery. √2(talk)06:03, 15 April 2024 (UTC)
sounds like the technical question is resolved and now it's an editorial issue. take it to the article's talk page? Jeremyb (talk) 06:51, 15 April 2024 (UTC)
However, Indiana was the most viewed state for the eclipse and now this Wikipedia page is making it look like it wasn't.
Although the photo from Dallas shows the finer details, the photo from Indianapolis shows us a greater aesthetic and the fact that Indianapolis was the hotspot for viewing the eclipse based on weather throughout the day and a bloom in tourism.
And it was the first total solar eclipse for Indianapolis since September 14, 1205.
And if it weren't for the weather forecast ahead of the event, Texas would've had more visitors than it did as many went to Indiana for the best spots. Eric Nelson27 (talk) 23:00, 15 April 2024 (UTC)
Tech News: 2024-16
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Problems
Between 2 April and 8 April, on wikis using Flagged Revisions, the "Reverted" tag was not applied to undone edits. In addition, page moves, protections and imports were not autoreviewed. This problem is now fixed. [57][58]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 April. It will be on non-Wikipedia wikis and some Wikipedias from 17 April. It will be on all wikis from 18 April (calendar). [59][60]
Default category sort keys will now affect categories added by templates placed in footnotes. Previously footnotes used the page title as the default sort key even if a different default sort key was specified (category-specific sort keys already worked). [61]
A new variable page_last_edit_age will be added to abuse filters. It tells how many seconds ago the last edit to a page was made. [62]
Future changes
Volunteer developers are kindly asked to update the code of their tools and features to handle temporary accounts. Learn more.
Four database fields will be removed from database replicas (including Quarry). This affects only the abuse_filter and abuse_filter_history tables. Some queries might need to be updated. [63]
I got a notification recently that there were recently multiple failed attempts to access my account, so I looked into enabling some kind of MFA. Allowing this for most/all users seems sensible since it would help prevent account compromises, and mult-factor auth is pretty common these days.
@Catleeball: Notifications of the kind you mention merely mean that somebody went to Special:UserLogin, entered your username, then had at least one try at guessing your password, and failed. This sort of thing happens to most of us from time to time, and is rarely worth worrying about - unless you habitually log in somewhere public, where somebody might be watching over your shoulder to see what you type. The way that I deal with it is to (i) always log out when finished editing, this kills all login cookies (regardless of which device they are stored on); (ii) change password from time to time, always doing so when in a private location; (iii) always use a strong password; (iv) don't use the same password on any other website (but note that because of WP:SUL, your password at French Wikipedia, Commons, Meta, Wiktionary etc. will always be the same as your English Wikipedia password). --Redrose64 🌹 (talk) 22:51, 15 April 2024 (UTC)
2FA is allowed for all users, just follow the instructions at meta:SRGP. It may seem like a pointless song-and-dance, but the idea is that saying "I have read the instructions" to a human has a greater effect than clicking an "I have read the instructions" button on a form. You'll be more likely to take the importance of backups seriously, and less likely to waste people's time after you lock yourself out of your account. I don't if that actually works in practice. Suffusion of Yellow (talk) 23:17, 15 April 2024 (UTC)
Did you mean to link the page for stewardship requests when you put meta:SRG there?
I fixed the link; that should be Meta:SRGP#Requests for 2 Factor Auth tester permissions. However, so long as you have a strong password that you do not use on any other site, you should be fine. You don't have any advanced permissions, so anyone attacking your account is going to move on to the next one after a few tries. The only exception is if there is a "catleeball" (or similar) account out there on some other site, with the same (or similar) password. If that site has been compromised, then it might only take a few tries to get in to your account. Suffusion of Yellow (talk) 23:48, 15 April 2024 (UTC)
Short answer: because if you screw up, you lose your account. WMF does not provide staff for an end-user helpdesk, and also doesn't collect other things that would maintain a reliable second-factor for recovery. — xaosfluxTalk15:43, 16 April 2024 (UTC)
I can't add a paragraph break after a table
At Head injury#Intracranial_bleeding, after the "Hematoma type" table, the text starts on the same line, i.e. to the right of the table, even when I add two new lines or <br/> after the table to try to put the next paragraph on a separate line. How can this be changed? (In case this is relevant: I'm viewing the page with the "Vector legacy" skin in Firefox 124.0.) - LaetusStudiis (talk) 15:30, 16 April 2024 (UTC)
The table was set to float left, possibly in a misguided attempt to align the text left. Gonnym has removed that now. Izno (talk) 16:23, 16 April 2024 (UTC)
pagelinks normalization
Hi, you might be aware that pagelinks table is being normalized (phab:T299947). I want to give enough time before dropping the columns. So here is the notice that the data has been fully populated in all Wikis except Turkish Wikipedia and Chinese Wikipedia (and these two wikis will finish in roughly a week). This means if you have tools or database reports in English Wikipedia that relies on pl_namespace or pl_title, you need to switch them to use pl_target_id ASAP. The rough estimate is that the old columns will be gone in a couple of weeks.
I was asked to make an explicit note here (one and two). Let me know if you have any question in the ticket. Thank you and my apologies for inconvenience. You can read more why we need to do this in phab:T222224. Best ASarabadani (WMF) (talk) 12:18, 15 April 2024 (UTC)
Thank you for the notification. Like the earlier templatelinks change, this will break to many on- and off-wiki tools (some of which may be unmaintained), and it's difficult to assess the likely scope of the damage. Here is a list of affected {{database report}}s, but there are plenty of other ways to use the table such as Quarry. Pinging R'n'B, who will probably be one of many with work to do. Certes (talk) 12:30, 15 April 2024 (UTC)
@ASarabadani (WMF): Would it be possible to add a view to the database which simulates the old pagelinks table by joining the new pagelinks table to linktarget? Then, updating our software would be as simple as replacing the word pagelinks by the name of the new view throughout. We would need to check that the performance hit of using the view is not significantly worse than what we will suffer anyway by adding the linktarget table explicitly. Certes (talk) 20:07, 15 April 2024 (UTC)
@Certes We sometimes do this to provide backward compatibility for short period of time but the main use of views is to hide private information (e.g. suppressed usernames, etc.) and adding layers of b/c increases complexity and has led to accidentally such information getting leaked and because of that we are avoiding to add b/c unless absolutely needed. I hope I have given enough time to people to update their tools. I"m sorry but this is something we have to do. ASarabadani (WMF) (talk) 10:05, 17 April 2024 (UTC)
Works for me if this is still a problem, please try turning off your personal javascripts (User:Zanahary/common.js and meta:User:Zanahary/global.js) then try again. — xaosflux Talk 11:12, 27 February 2024 (UTC)
Gadgets allow interface admins to create custom features with CSS and JavaScript. The 
The new version of MediaWiki will be on test wikis and MediaWiki.org from 5 March. It will be on non-Wikipedia wikis and some Wikipedias from 6 March. It will be on all wikis from 7 March (calendar). [6][7]
Resolved
Resolved
TFOWR (talk · contribs · former admin: blocks · protections · deletions · rights · meta · local rights)
Done, sorry for dis-regarding this Cocobb8 (💬 talk • ✏️ contribs) 15:10, 16 March 2024 (UTC)
Fixed. – Jonesey95 (talk) 04:41, 23 March 2024 (UTC)
A new Edit Recovery feature has been added to all wikis, available as a user preference. Once you enable it, your in-progress edits will be stored in your web browser, and if you accidentally close an editing window or your browser or computer crashes, you will be prompted to recover the unpublished text. Please leave any feedback on the project talk page. This was the #8 wish in the 2023 Community Wishlist Survey.
Moved from Wikipedia talk:Village pump
You are invited to join the discussion at Module talk:Wd § Getting Template:Update tracker working with qualifiers. Sdkb talk 14:03, 10 April 2024 (UTC)
_2024-03-03.png){kind=link}
![[53]](https://phab.wmfusercontent.org/file/data/lmqmphebmpv72akm3yyw/PHID-FILE-i2qspdrcf3kvw67yerug/image.png){kind=link}
.jpg){kind=link}