Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

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

« Archives, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Search autocomplete selects random results when arrowing down

Tracked in Phabricator
Task T379983
Resolved

I've recently tried to search a few things, and noticed that if I press arrow down on the autocomplete results, it selects a random result, rather than the expected outcome of it selecting the first in the list (then going down one if pressed again, etcetera). For example, to test this, I typed in "AS" into the search bar, which displayed "AS", "Association football", "Associated Press", "Assassination of John F. Kennedy", among others. I pressed the arrow down, and it highlighted the last result, "ASEAN". I pressed it again, and it highlighted "Asperger syndrome", which is the 6th result in the list, and 4 results up from "ASEAN". This continues for some time, but it generally jumps through the list at random intervals. I checked that I had safemode on before trying this, and I am on the latest version of 64-bit Chrome, version 131.0.6778.70. EggRoll97 ^(talk) 01:11, 15 November 2024 (UTC)

Given the day, by the way, it may be WP:THURSDAY, but I'm not necessarily sure if that indeed is the case. EggRoll97 ^(talk) 01:13, 15 November 2024 (UTC)

Me too, Windows 10 version 22H2, Firefox 132.0.2 (recent upgrade), all skins except Vector-2022 and Minerva Neue, logged in and logged out. The main symptom seems to be that in the search box, the functions of the up and down arrows are exchanged. Also affects commons:. --Redrose64 🌹 (talk) 01:22, 15 November 2024 (UTC)

This is probably related to phab:T379983 though of course you can report a separate task. Izno (talk) 01:33, 15 November 2024 (UTC)

Looks like it, and it appears a change has been merged so this should (hopefully) resolve itself fairly soon. EggRoll97 ^(talk) 01:38, 15 November 2024 (UTC)

I'm facing the same issue, on Vivaldi (7.0.3495.11 (64-bit)) on Windows 11 Home 23H2. Are you on Wikipedia's 2010 Vector legacy skin (the old default GUI) by any chance? I have this issue on that skin but not on Wikipedia's new Vector skin. Tube·of·Light 11:21, 15 November 2024 (UTC)

I'm having the same issue on Firefox 128.4.0 with Vector 2010 on macOS 12.7.6. – dudhhr ^talk_contribs^she_her 22:57, 15 November 2024 (UTC)

I don’t see anyone mentioning it anywhere, but I am also having the same issue on Timeless. win8x (talking | spying) 14:46, 16 November 2024 (UTC)

@Win8x: As I wrote above, all skins except Vector-2022 and Minerva Neue. --Redrose64 🌹 (talk) 16:52, 16 November 2024 (UTC)

Oops I didn't properly read. Glad a change has been merged though. win8x (talk) 16:53, 16 November 2024 (UTC)

Resolved

Now working as expected. --Redrose64 🌹 (talk) 18:05, 20 November 2024 (UTC)

Does Pending Changes disable edit conflict checking?

I haven't found any documentation about this at Wikipedia:Pending Changes, mw:Help:Extension:FlaggedRevs, mw:Extension:FlaggedRevs, or phab:T185664. (I am an idiot though, and frequently miss obvious information.)

But here's what happened (all these diffs are sequentially uninterrupted BTW): while WP:HD was under PC protection (LTA disruption), T=00 I reply to a thread. T+02 minutes, PrimeHunter replies. T+17 minutes, OP replies to my reply, removing PrimeHunter's reply with no edit summary (edit tagged as "2017 wikitext editor"). A bit later, I notice this and enter the source editor within Minerva to restore PrimeHunter's edit without automatically adding my sig. T+44 PrimeHunter restores the edit. T+46 I do too. Despite the edit summary of my immediate self-revert, I was never shown an edit conflict error (these do work in Minerva: I had three recently at heavily trafficked pages, all in ns4).

My interpretation of this sequence is that since FlaggedRevs are "automatically accepted" when the editor permissions allow, checking for edit conflicts is disabled or hampered in some way, at least in some editing interfaces. Can anyone confirm this? Folly Mox (talk) 18:13, 16 November 2024 (UTC)

Well, PrimeHunter restored text above the 2 lines :I think this was [...] and :: I haven't had this [...], while you restored it below those 2 lines, that's why there was no edit conflict. I actually don't know the exact logic, though something is mentioned at mw:Help:Edit conflict#Preventing edit conflicts - I've always assumed that it's the same logic that governs if you can still undo a revision after new revisions have been made (which from experience is when the diff of that revision would not have revealed lines that changed in later revisions). – 2804:F1...C6:3070 (::/32) (talk) 22:46, 16 November 2024 (UTC)

For clarity, here is a multi-revision diff of both of your restorations: Special:Diff/1257208774/1257214231. – 2804:F1...C6:3070 (::/32) (talk) 22:56, 16 November 2024 (UTC)

2804:F14:8085:6D01:BC4B:E524:C2C6:3070, I assume it's paragraph-based like the diffs. — Qwerfjkltalk 18:06, 17 November 2024 (UTC)

Huh, ok; I thought edit conflicts were partitioned by subheading, but the "same line" implementation makes sense here, while also making sense at the other three edit conflicts I did experience, since other editors and I were adding text to the same (empty) line. Thanks both for the information 🙏🏽 Folly Mox (talk) 13:47, 21 November 2024 (UTC)

Strip marker problem with template

It looks like 92 articles (possibly more) with {{election box candidate with party link}} templates are exposing strip markers (?UNIQ...QINU?). It seems like the issue is related to ref tags being used within the template. Example articles include Sussex East (European Parliament constituency), 1970 Florida Attorney General election, and Kocaeli (electoral district). I’m not sure how to resolve this, so I'm posting here. Daniel Quinlan (talk) 23:09, 17 November 2024 (UTC)

Probably has to do with the string replacement on the |change= parameter. Probably the easiest is to create a |change_note= parameter so it doesn't clash with that. Gonnym (talk) 23:27, 17 November 2024 (UTC)

{{Election box candidate with party link}} says {{#invoke:String|replace|source={{{change|}}}|-|−}} to change a hyphen to a minus sign in a negative number. If the parameter has a reference then its strip marker code has four hyphens which are also changed and this breaks the code. I suggest {{#invoke:String|replace|source={{{change|}}}|^-|−|plain=false}} to only change a hyphen if it's the first character. Then the articles don't need a new parameter for a note. Before editing a template used in 29,000 pages, does anyone have objections or a better solution? The bad cell in 1970 Florida Attorney General election#Results uses {{Election box winning candidate with party link}} which would need the same fix. PrimeHunter (talk) 00:08, 18 November 2024 (UTC)

Could it be further restricted to also require the hyphen to be followed by a digit? Daniel Quinlan (talk) 00:29, 18 November 2024 (UTC)

To elaborate, I was thinking something like {{#invoke:String|replace|source={{{change|}}}|^%s*-(%d)|−%1|plain=false}}. Daniel Quinlan (talk) 02:30, 18 November 2024 (UTC)

I see you also strip whitespace at the start. It should probably be done by a new template so complicated code doesn't have to be duplicated. This search finds 20 cases just in Category:Election and referendum infobox templates. PrimeHunter (talk) 21:40, 19 November 2024 (UTC)

Lockout script misbehaving

I have a forked version of User:Anomie/lockout.js in my common.js which only blocks editing, not viewing. However, if the edit page is opened by DraftCleaner, the edit page isn't blocked and I can edit as usual, including if other scripts refresh the page. Why does this happen, and is there a way to block the edit page in this case? Suntooooth, it/he (talk/contribs) 03:31, 19 November 2024 (UTC)

Suntooooth, that's because DraftCleaner uses ?action=submit to open the editor, while your lockout script only checks for ?action=edit. You could change the condition of the if-statement to something like !["edit", "submit"].includes(mw.config.get("wgAction")). Rummskartoffel 21:21, 23 November 2024 (UTC)

I'll try that out, thank you! :] Suntooooth, it/he (talk/contribs) 18:46, 24 November 2024 (UTC)

Social media post template

There's a discussion over at Template talk:Tweet#Post template about creating a new social media post template, that would look an act the same as the current {{Tweet}} template but extended for other social sites. A result of this was {{SocialMediaPost}}, but this seems like a very manual solution, liable to breaking and inconsistencies. I was wondering if something could be created which could, given a "website" param, automatically select the correct "site logo", "article Link", "reference format" and "prefix", similar to the way {{Political party}}s or {{Infobox legislation}} are done. Or if I'm other thinking it and the manual method is fine. Cakelot1 ☞️ talk 09:50, 19 November 2024 (UTC)

It is possible, sure. It will require some work. Izno (talk) 17:16, 19 November 2024 (UTC)

Hi! Sorry for kind of jumping the gun on moving this to the template space. I'm not the best at templates, but I'll definitely take a look at those ones you linked and see if i can do anything to automate the process. It's been a bit since I've actually used Lua, but I'll try. Generating that information off of a 'website' parameter seems doable, and i'll let y'all know if i manage to make progress. Tantomile (talk) 19:41, 19 November 2024 (UTC)

In-line citation tag

Helo! I have spent way too much time trying to find the template which askes for more in-line citations in the sourcing of an article. Wading through page after page hasn't done the trick. Can anyone here please help me find it? SergeWoodzing (talk) 13:09, 19 November 2024 (UTC)

{{No footnotes}}? DMacks (talk) 13:14, 19 November 2024 (UTC)

Thank you! --SergeWoodzing (talk) 13:19, 19 November 2024 (UTC)

If it has some inline cites but could use more there's {{more footnotes needed}}. -- LCU ActivelyDisinterested «@» °∆t° 23:40, 19 November 2024 (UTC)

I'm not sure if you were already aware of it, but just in case you're not: WP:TC is a very useful list for this sort of thing. Suntooooth, it/he (talk/contribs) 18:23, 19 November 2024 (UTC)

Lua errors

Can someone explain what's wrong here? si:විකිපීඩියා:Templates for discussion VihirLak007^hmu!/_duh. 15:31, 19 November 2024 (UTC)

It looks like Lee imported a load of templates and modules from the English wikipedia which are designed to take English language inputs. The "time errors" for example, are because si:Module:YMD to ISO converts English date strings to an ISO formatted date, but you are giving it Sinhala month names (because the output of {{#time: depends upon the language of your wiki). You either need to go through and localise all the templates that were imported, or make new ones for your wiki. 86.23.109.101 (talk) 17:49, 19 November 2024 (UTC)

Thanks. Sounds like it gonna take a while to solve the issues tho VihirLak007^hmu!/_duh. 18:37, 19 November 2024 (UTC)

Any idea how to localize and what templates/modules to localize? VihirLak007^hmu!/_duh. 19:02, 19 November 2024 (UTC)

@VihirLak007 It would probably be amount the same amount of work to start from scratch rather than getting that module to work. The module takes input in the form 19 November 2024 or 19 Nov 2024, i.e. two numbers followed by the month name or abbreviation, followed by four numbers. The output of {{#time: on your wiki seems to be 2 Sinhala numerals (I think? I don't speak Sinhala) followed by the month in Sinhala, and the year. At a minimum you would need to translate the month names, add new logic to convert the Sinhala numerals to Arabic numerals, re-write all the input checks to account for the difference in format, possibly remove the logic for the month name abbreviations ... 86.23.109.101 (talk) 19:02, 19 November 2024 (UTC)

in sinhala, the numerals are same, arabic numerals. i think if i add sinhala month names alongside where it takes english names, it might work? The thing is i've no idea where to edit VihirLak007^hmu!/_duh. 19:05, 19 November 2024 (UTC)

@VihirLak007 In that case you would need to add the Sinhala names alongside the English ones, and also change the pattern matching checks at the bottom (the bit that goes arg1:match('^%d%d%d%d %a%a%a%a?%.?%a?%a?%a?%a?%a?%a? *%d%d?$')) to allow the new date formats. 86.23.109.101 (talk) 19:09, 19 November 2024 (UTC)

Sorry for being lost minded here. Where should i add the sinhala names? i know how to add but not sure where. VihirLak007^hmu!/_duh. 19:15, 19 November 2024 (UTC)

The Sinhala names would just replace the English ones in the months_full variable. I'm not sure what you'd need to do to update the pattern matching, sorry. 86.23.109.101 (talk) 19:20, 19 November 2024 (UTC)

Any idea where to find the place that controls the output of {{#time on Sinhala wiki? VihirLak007^hmu!/_duh. 20:11, 19 November 2024 (UTC)

@VihirLak007 See MW:help:parserfunctions##time. 86.23.109.101 (talk) 20:40, 19 November 2024 (UTC)

{{#time:...|en}} will format the output in English at any wiki. PrimeHunter (talk) 21:26, 19 November 2024 (UTC)

RFC references in Further Reading

@Neko-chan: Recent edits to § Further Reading by Neko-chan have changed some, but not all,RFC references to {{IETF RFC}}. Should this not be consistent?

I was going to suggest ussing {{Ref RFC}}, but it is still a stub, e.g., {{Ref RFC|5321}} produces "". -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:41, 20 November 2024 (UTC)

Thank you for pointing out some things I missed, can you link to exactly which article? That further reading link doesn't go anywhere. ~ฅ(ↀωↀ=)neko-chan^nyan 16:14, 20 November 2024 (UTC)

Oh, it's still pretty early in my time zone and I misread. Maybe I should get some coffee.

If this is Email_address#Further_reading, then they're not references, they're inline links which is what {{IETF RFC}} is for. It's not inconsistent, they have different purposes. I also didn't swap the {{cite IETF}} citations because {{ref RFC}} doesn't handle section cites properly. ~ฅ(ↀωↀ=)neko-chan^nyan 16:26, 20 November 2024 (UTC)

Sorry, the template I used, {{alink|Further Reading}}, is only valid in Talk:Email address; I should have used {{slink|Email address|Further Reading}}yielding Email address § Further Reading.

The inconsistency I referred to is the one that you corrected with permalink/1258604111. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:49, 20 November 2024 (UTC)

References

RfC notice: Log the use of the HistMerge tool at both the merge target and merge source

There is currently a discussion at Wikipedia:Village pump (proposals) regarding the logging functionality of the Special:MergeHistory tool. The thread is RfC: Log the use of the HistMerge tool at both the merge target and merge source. Thank you. — Red-tailed hawk _(nest) 16:00, 20 November 2024 (UTC)

Special:Badtitle in pending changes notice

Tracked in Phabricator
Task T380519

Over at Silk Road (marketplace) where there was a pending changes notice on the history tab, the links in it were all broken with Special:Badtitle being used. Looking at Special:PendingChanges this seems to affect other article titles as well. It seems to be an issue with mw-fr-revision-tag-edit:

<div id="mw-fr-revision-tag-edit" class="cdx-message mw-fr-message-box cdx-message--block cdx-message--notice flaggedrevs_notice plainlinks"><span class="cdx-message__icon"></span><div class="cdx-message__content">The <a class="external text" href="https://en.wikipedia.org/w/index.php?title=Special:Badtitle/Message&amp;stable=1">latest accepted version</a> was <a class="external text" href="https://en.wikipedia.org/w/index.php?title=Special:Log&amp;type=review&amp;page=Special:Badtitle/Message">reviewed</a> on <i>20 November 2024</i>. There is <a class="external text" href="https://en.wikipedia.org/w/index.php?title=Special:Badtitle/Message&amp;oldid=1258565930&amp;diff=cur&amp;diffonly=0">1 pending revision</a> awaiting review.</div></div>

SmartSE (talk) 12:22, 21 November 2024 (UTC)

Pisco is currently listed at Special:PendingChanges so https://en.wikipedia.org/w/index.php?title=Pisco&action=history shows the issue right now. The message is made by MediaWiki:Revreview-pending-basic. We have customized it but the links are generated in the same way as the default message and the problem is also seen for an uncostumized message with uselang=de (German). The message uses {{FULLPAGENAMEE}} which apparently returns Special:Badtitle/Message in that message. The same history page uses MediaWiki:Histlegend where {{FULLPAGENAMEE}} works correctly. MediaWiki:Revreview-pending-basic is from an extension. Maybe that causes the difference. We got 1.44.0-wmf.4 today. If the issue started today then it sounds like WP:ITSTHURSDAY with a problem in something at mw:MediaWiki 1.44/wmf.4. PrimeHunter (talk) 13:15, 21 November 2024 (UTC)

Here is a quick and dirty fix for your common JavaScript:

document.body.innerHTML = document.body.innerHTML.replace(/Special:Badtitle\/Message/g, mw.config.get('wgPageName'));

It changes Special:Badtitle/Message everywhere (maybe the bug affects other messages) including in the edit window for this section, so don't edit it if you add the fix. PrimeHunter (talk) 13:56, 21 November 2024 (UTC)

I don't see a phabricator ticket. PrimeHunter, do you want to write something up? I'm wondering if this has something to do with * git #016644c4 - Do not pre-parse MessageValue arguments (T380045) by Isabelle Hurbain-Palatin? I did do a quick test to confirm that {{FULLPAGENAMEE}} (or {{FULLPAGENAME}}) are directly producing the Special:Badtitle/Message text, it's not just happening when passed through {{fullurl:}} or when linked.--Ahecht (TALK
PAGE) 15:06, 21 November 2024 (UTC)

I have created phab:T380519. PrimeHunter (talk) 18:13, 21 November 2024 (UTC)

I have made a partial fix [1]. It fixes the third and most important link in the message by omitting the bad title. A title is unnecessary in diff links. PrimeHunter (talk) 21:34, 21 November 2024 (UTC)

code editor

Yep, I know, Thursday. Something has happened to the code editor. When I start typing, the code editor now pops up a window that shows a list of text strings that may match what it is that I'm typing. This list is not constrained to Lua keywords but apparently is a list of all words in the module. How do I turn that off?

—Trappist the monk (talk) 00:15, 22 November 2024 (UTC)

Try this in your CSS:

.ace_autocomplete {display:none;}

PrimeHunter (talk) 01:30, 22 November 2024 (UTC)

Copying from the phab:T377663 phab comment:

• You can disable it by pressing Ctrl + , and unticking "Live Autocompletion".

(I was looking to see why the change hadn't been proposed for Tech News, and I see someone has just tagged it yesterday, so it will be included next week.) Quiddity (WMF) (talk) 01:57, 22 November 2024 (UTC)

Thanks both, Ctrl + , worked. I wonder who thought that key combination is intuitive? Wasn't there a Dilbert comic about such shortcuts?

—Trappist the monk (talk) 12:32, 22 November 2024 (UTC)

@Quiddity (WMF) That's useless because, even if it were documented somewhere, it doesn't persist. You have to re-set that preference every time you load the editor, even if you just hit the "preview" button. --Ahecht (TALK
PAGE) 15:18, 22 November 2024 (UTC)

Proposed change to tabs on redirect pages

I am proposing in phab:T5324#10347051 that the page tabs on redirect pages (‘Article/Talk’ and ‘View’ depending on the page) get a small improvement: they would link to redirect pages themselves by default. Currently they link to their targets with a possibility of navigating back. The change should improve navigation from other actions, like going from history page for "WOW" redirect to the redirect page itself. This should be especially beneficial for English Wikipedia since this community has a system of redirect templates. You would still be able to navigate to redirect target, just with an additional click.

Please let me know either here or on Phabricator (by awarding a token or leaving a comment there) if you are for, against or indifferent to this potential change. It was previously announced in Tech News in 2020 but no one went on to actually review the change. Hopefully this time would be different. stjn 01:24, 22 November 2024 (UTC)

Unsurprisingly, I agree with the change, having reopened the Phabricator task in 2019. I was using this one-liner to mitigate for a while.

The talk page behavior is likely more contentious: essentially this turns talk page redirects into soft redirects when clicking on the 'Talk' tab, which is probably the most common way of accessing them. Numerous closely-related templates use redirects to centralize discussion (example: Template talk:Cite news and related templates). Bot talk pages often redirect to the bot operator's talk page (5/10 of the top 10 active bots by edits do this: 1, 2, 3, 4, 5). Also in Wikipedia namespace you can find cases like AN and ANI that have a merged talk. Retro (talk | contribs) 06:56, 22 November 2024 (UTC)

Those are all cases where a normal page has a redirected talk page. I think the proposed change would only apply to redirects with redirected talk pages. jlwoodwa (talk) 07:32, 22 November 2024 (UTC)

Yeah, if that's the case, there's no issue. Retro (talk | contribs) 07:52, 22 November 2024 (UTC)

If I understood correctly even in the case of going from a redirected article to a redirected talk page it would go to the target of the redirected talk page. The change as I understood would be:

• When going from history, info,... of a redirected article to the article itself it would stay in the redirect
• When going from history, info,... of a redirected talk page to the talk itself it would stay in the redirect

Going from a redirected article to the redirected talk page would still behave as it does now. -- Agabi10 (talk) 09:07, 22 November 2024 (UTC)

Looking at the current version (Patchset 2) of gerrit:r/1094077, your second bullet is not correct. The behavior is simpler:

• The talk tab would still follow the redirect, except when the talk tab is the current tab (e.g. you're already on the talk page with &redirect=no, or viewing the talk page history).
• The subject tab would always stay in the redirect.
• Extra tabs, such as TimedText on Commons or Source on Wikisource, will work similarly: stay on redirect if pointing to a subject namespace or are the current tab, follow redirect if pointing to a talk namespace and non-current.

Personally, I'm not so sure of this behavior change. When I'm already at a &redirect=no, I tend to click on the tab to follow the redirect. Clicking the link in the "soft-redirect" on the redirect=no page has different behavior in some edge cases (e.g. double redirects) and won't show the "redirected from" on the target page. OTOH, it's better than the more-consistent alternative that Retro was concerned about above, which would have made it much more likely for people to start commenting on redirected talk pages. Anomie⚔ 13:01, 22 November 2024 (UTC)

The current Gerrit patchset is a first attempt at implementing this. It should not be referenced as what I want to achieve. Ideally, only the tabs related to the currently viewed page would have redirect=no added. So TimedText/Source etc. should only be affected when they are the current page and user is viewing something related to the redirect.

Currently, there is no way to get to view the redirect page in one click even if you are on edit/history pages. That is more unacceptable than someone being a bit inconvenienced by having to click to the big article name and not the tab. stjn 13:23, 22 November 2024 (UTC)

How often do people really need to get to view the redirect page that one click rather than two for this use case outweighs the drawbacks of increasing the inconsistency of the UI and requiring editing the URL to follow the redirect as a reader would? Anomie⚔ 13:11, 23 November 2024 (UTC)

‘Increasing inconsistency’ is your personal opinion that multiple people already disagreed with. In my opinion, it would decrease the inconsistency, as all the other page tabs relate and point to the current page, and not to the redirect target, so the main ones should, too. Currently people are already required to edit the URL, just in the other direction. stjn 14:32, 23 November 2024 (UTC)

The inconsistency I referred to is that, with your proposed change, the tab will sometimes follow the redirect and sometimes not. PS6 seems intended to make it more sometimes-and-sometimes-not. As for URL editing, people don't have to edit the URL to get to the redirect page now, but they do need two clicks: one on the tab, following the redirect, and then one the "Redirected from" under the page title to get to the redirect itself. Anomie⚔ 23:59, 23 November 2024 (UTC)

When I started on Wikipedia, waaaay back in May 2009, if you clicked on a link for a redirect, the redirection would occur client-side and your browsing history would get two entries: one for the redirect page, and one for where you got redirected to. An effect of this was that you needed to use the browser's "back" feature twice in order to return to where you first came from. A bonus side effect was that if you only used "back" once, you could then work on the redirect page directly - "edit", "history", etc., even "move" if you were that silly. Nowadays the redirection is performed server-side, which in some ways makes it harder. --Redrose64 🌹 (talk) 00:31, 24 November 2024 (UTC)

The tab will follow the redirect when you are not looking at the redirect page and won’t when you are. That is not inconsistent.

The workflow you described in the last sentence can also be described as requiring people to edit the URL to get to the redirect page, since it is much easier to copy the URL and then add ?redirect=no than it is to aim at the barely visible ‘Redirected from’ notice (especially for section redirects, which do not show it at all, see phab:T360255 / phab:T169282). stjn 21:19, 24 November 2024 (UTC)

Section redirects do show it, they're in the usual place below the page title. You just have to hit the Home key, that's all. --Redrose64 🌹 (talk) 22:46, 24 November 2024 (UTC)

Gerrit patch was improved to not affect the non-current or extra tabs. stjn 15:41, 22 November 2024 (UTC)

I only mean that if someone is on the redirect talk page, they should be able to navigate to it from ‘Talk’ tab. Otherwise (‘Talk’ page on non-talk pages) there should be no change. stjn 12:42, 22 November 2024 (UTC)

My initial thought is that this seems fine, since it'll only affect editors (readers have basically no reason to end up at a redirect page). But overall we should be careful not to focus unduly on our editing needs over their reading needs. Sdkb ^talk 17:04, 22 November 2024 (UTC)

I'm confused about what is being proposed here, so I'll just say that if the URL of the page I'm viewing includes "redirect=no" then I want that to be preserved when I click the article or talk tabs. When I'm viewing the non-redirected talk page of a redirect and click the article tab I could be wanting either the reidrect or its target, probably the former about two thirds to three quarters of the time, but as someone who does a lot of work with redirects I don't know how typical my workflow is. Thryduulf (talk) 13:55, 23 November 2024 (UTC)

Mobile wikipedia images problem

Images on the sides of articles don't show up with Javscript disabled on en.m.wikipedia.org, only their captions. Images in the infobox and the main page load normally. If you don't want to show images in articles to users who disable Javascript in Firefox please remove the captions too so there's no clutter. 31.217.45.191 (talk) 14:34, 22 November 2024 (UTC)

It works for me with Firefox 132.0.2 (64-bit) on Windows 10, JavaScript disabled, both logged in and out. For example, I see File:SN1998aq max spectra.svg at Type Ia supernova#Consensus model. Do you see the image on the article? On the file page? At https://upload.wikimedia.org/wikipedia/commons/2/25/SN1998aq_max_spectra.svg? If you see it on the article then please give an example you don't see. PrimeHunter (talk) 16:21, 22 November 2024 (UTC)

My bad, I accidentally disabled <noscript> tags too in my browser. Sorry 31.217.45.191 (talk) 19:35, 22 November 2024 (UTC)

Electcom seeks technical assistance

Resolved

 – Thank you everybody for your input. I think we've got this resolved now. RoySmith (talk) 16:00, 23 November 2024 (UTC)

In dealing with an issue, electcom implemented Special:Diff/1258984383 which unfortunately broke the question numbering. I'd appreciate any suggestions on what wikimarkup could be used to keep the hatted text hatted and also preserve the question numbering sequence. RoySmith (talk) 00:19, 23 November 2024 (UTC)

Is this still a problem? I see the question numbers, including the collapsed one at question 21. If still an issue, please describe the problem a bit more. — xaosflux ^Talk 00:38, 23 November 2024 (UTC)

Try uncollapsing the text, and then try adding a new question beneath the old one. Izno (talk) 00:41, 23 November 2024 (UTC)

{{ACE Question}} is implemented in a way which makes this practically impossible without something in the hatted text looking off if you collapse things. It basically assumes the structure of the container (an ordered list) and then indents the answer with wikitext #:. That is a flaw of that template that cannot be corrected without some non-0 study. Izno (talk) 00:41, 23 November 2024 (UTC)

Not only that, but {{hab}} only works if it's added at a new line, which would break the numbering either way.

The way it is currently the hat just swallows new questions, the hab having no effect. – 2804:F1...86:EF41 (::/32) (talk) 03:01, 23 November 2024 (UTC)

The easy answer is just to remove the text instead of collapsing it. —Cryptic 00:45, 23 November 2024 (UTC)

OK, thank you all for the assistance. We'll put our heads together off-wiki and figure out a plan. RoySmith (talk) 00:50, 23 November 2024 (UTC)

You could create a wrapper div for the questions after 21 with a special class name, then create a style sheet (using Wikipedia:TemplateStyles) that sets the starting number of the ordered list within that div. isaacl (talk) 01:52, 23 November 2024 (UTC)

More kludgily, since the list would be the second ordered list in the content area, the corresponding style sheet rule could be written to target the second ordered list. That would avoid the need for a wrapper div. isaacl (talk) 02:00, 23 November 2024 (UTC)

The style rule would be something like the following:

.mw-body-content ol:nth-of-type(2) li:nth-of-type(1)
{
  counter-set: list-item 22;
}

isaacl (talk) 02:45, 23 November 2024 (UTC)

@Isaacl: You don't need to go to those lengths. Ordered lists can be fudged directly, check this out:

Here is a list:
#This is the first item
#Second item
#<li value=4>Not the third item
#List continues
with text after.

It's demonstrated at WP:Sandbox. --Redrose64 🌹 (talk) 14:49, 23 November 2024 (UTC)

From an accessibility point of view, is any other choice other than replacing with text (maybe with a permalink if you want it to be accessible) even good?

The only thing I found that sorta works is wrapping it all in a {{efn|1= ... }}, but then you have to add a notelist somewhere where the question will actually appear (collapse and all). That doesn't break the numbering of the questions afterwards. – 2804:F1...86:EF41 (::/32) (talk) 03:40, 23 November 2024 (UTC)

• @RoySmith: To be honest, I don't think it needs a complicated technical response. ARBPIA states that this restriction may be enforced by other methods, including ... reverts, and that applies On any page where the restriction is not enforced through ECP. So you can just get rid of it, much easier. SerialNumber54129 15:34, 23 November 2024 (UTC)
• Thank you for unboxing, Redrose64. It was bloody uncivil of RoySmith to shut it off in the first place. SerialNumber54129 20:52, 23 November 2024 (UTC)

  I didn't mean to be uncivil. I had the answers I needed, that was all. If folks want to continue to chat about this, please feel free to do so. RoySmith (talk) 21:15, 23 November 2024 (UTC)

Article incorrectly marked as List class

I noticed that the article Femke is wrongly marked as List class on the talk page, where it should have been marked as GA class, like I believe it was previously, but now the class in the banner shell appears to be overridden. I suspect that this is somehow caused by / related to the {{given name}} template, despite the section=y parameter that indicates only one section and not the whole article contains a list of given names. Could this be fixed? – Editør (talk) 09:21, 23 November 2024 (UTC)

@Editør: This is due to recent changes at Module:Banner shell. You should see if there's anything on the matter at Template talk:WikiProject banner shell. If there isn't, raise a thread on that page and and notify MSGJ (talk · contribs) when doing so. --Redrose64 🌹 (talk) 14:16, 23 November 2024 (UTC)

Thanks. I couldn't find this topic on the talk page, so I added it as advised. – Editør (talk) 17:17, 23 November 2024 (UTC)

The first sentence of that template says Template:given name is only for use on Wikipedia set index articles. If Femke isn't a set index article, then that template shouldn't be used there. Misusing templates can and usually does, break other things. Remove the template from that page and the banner should work. Gonnym (talk) 14:49, 24 November 2024 (UTC)

Thank you for your comment, I've replied here. – Editør (talk) 18:24, 24 November 2024 (UTC)

Concern involving User:MusikBot II/TemplateProtector

Moved to User talk:MusikAnimal

JJP_Master (she/they) 19:49, 23 November 2024 (UTC)

Problems with WP:Twinkle

Moved to Wikipedia talk:Twinkle § Problems with WP:Twinkle

 – – SD0001 (talk) 16:56, 24 November 2024 (UTC)

Discussion at Wikipedia talk:Editnotice § adding a backlink to edit notices

 You are invited to join the discussion at Wikipedia talk:Editnotice § adding a backlink to edit notices. Sdkb ^talk 06:23, 25 November 2024 (UTC)

Revision slider missing?

I am not sure if I changed something, but I've checked my common.js and preferences ("Don't show the revision slider" not checked) but the revision slider ("Browse history interactively") is not showing. Did I do something wrong or is it disabled? </MarkiPoli> <talk /><cont /> 11:38, 25 November 2024 (UTC)

Oh, it seems to be only on diff pages, not the "old revision" pages.</MarkiPoli> <talk /><cont /> 11:44, 25 November 2024 (UTC)