Wikipedia:Village pump (technical)

Policy

Technical

Proposals

Idea lab

WMF

Miscellaneous

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

Shortcuts

• WP:VPT
• WP:VP/T
• WP:TECHPUMP
• WP:PUMPTECH

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.

view · edit Frequently asked questions (see also: Wikipedia:FAQ/Technical) Click "[show]" next to each point to see more details. If something looks wrong, purge the server's cache, then bypass your browser's cache. This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown. No, we will not use JavaScript to set focus on the search box. This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences. No, we will not add a spell-checker, or spell-checking bot. You can use a web browser such as Firefox, which has a spell checker. If you have problems making your fancy signature work, check Help:How to fix your signature. If you changed to another skin and cannot change back, use this link. Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem. If an image thumbnail is not showing, try purging its image description page. If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear. For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

For over a year, I have used insource regex searching intensively. One of its most valuable features was that it gave a total number of matches.

My search for untagged, unbracketed bare URLs is insource:/\<ref( [^\>]*)?\>https?:\/\/[^ \<\>\{\}]+ *\<\/ref/i. Until this evening, it was reporting a total of ~44K hits. Now it always reports 10,000.

This is a real loss of utility. It deprives me of my main tool for monitoring progress in between the twice-monthly database downloads.

Why has this happened? BrownHairedGirl (talk) • (contribs) 22:10, 8 September 2022 (UTC)[reply]

We are in the process of upgrading from Elasticsearch 6.8.23 to Elasticsearch 7.10.2. This behavior changed in ES7; now queries are early-stopped at a count of 10,000 to save CPU time.

Previously, while the number of actual documents returned would never be more than 10,000, it would still return the full count (the ~44k hits you were seeing).

It sounds like there's a setting we can flip to switch the count behavior back to how it was previously.

We'll have a phabricator task up for this in a bit so I'll circle back to edit this response with a link to that ticket in a little bit.

Thanks for reporting the behavior change, it's very helpful for us to get a feel for users' workflows. RKemper (WMF) (talk) 22:41, 8 September 2022 (UTC)[reply]

And that ticket is T317374. :) Legoktm (talk) 22:42, 8 September 2022 (UTC)[reply]

Thanks, @Legoktm & @RKemper (WMF).

The full count is really useful for many tasks. I use it many times a day for that search, but also as many times again for various other regex searches. It's great to be able to ask "how big is this issue" and get a prompt answer. BrownHairedGirl (talk) • (contribs) 23:09, 8 September 2022 (UTC)[reply]

I know we're not supposed to say "Me too" on Phab, so here it is in the right place: "Me too!" This feature is invaluable. – Jonesey95 (talk) 23:28, 8 September 2022 (UTC)[reply]

@Jonesey95. Might want to click "Award Token" on Phab and give it a thumbs up. That's an un-spammy way to support a ticket. Hope that helps. –Novem Linguae (talk) 23:59, 8 September 2022 (UTC)[reply]

Yes, this is a feature I was using. I just found out that it was capped today so like @Jonesey95 and @BrownHairedGirl have said it would be helpful for the total count to show, even if it doesn't reutrn more than 10,000 results (like it did in the past). Rlink2 (talk) 13:28, 9 September 2022 (UTC)[reply]

Circling back here: we've merged a patch that should restore the previous count behavior. This patch won't go live until the next backport deploy or deployment train. Our current goal is to get it out during the Monday Sep 12 US backport window, so if you all haven't heard anything by Tuesday US time, feel free to ping me/us again here or on IRC (#wikimedia-search) for an update. RKemper (WMF) (talk) 18:57, 9 September 2022 (UTC)[reply]

Many thanks, @RKemper (WMF), both for your prompt action on this and for your courtesy throughout. I look fwd to the fix. BrownHairedGirl (talk) • (contribs) 19:11, 9 September 2022 (UTC)[reply]

Update: We've rolled out the new setting. I tried @BrownHairedGirl's query and can confirm I see the full 44k+ hits listed. RKemper (WMF) (talk) 07:26, 13 September 2022 (UTC)[reply]

Thanks for the rollout, @RKemper (WMF).

The full count is indeed being listed, @RKemper (WMF). Thanks for you work on this.

However this has confirmed another problem which I had glimpsed in the past week: that the new search is much more susceptible to timeouts.

Before the switch to Elasticsearch 7, my bare URLs search timed out only very occasionally, and only at periods of peak load, i.e. 2100–0600

However, now my bare URLs search times out on nearly every attempt. Even at 1000 UTC, I still had to try three times to get a full set, without timeout.

The behaviour within AWB is even more annoying. Since May 2022, I have at least once every day (and more often 2-3 times) used exactly that same search within AWB, to generate lists to feed to @Citation bot. It always produced 1,000 hits the maximum permitted by AWB; never any less, in hundreds of uses. But since the arrival of Elasticsearch 7, about half of those with-AWB searches return less than 1,000 hits; only morning-time UTC and early afternoon is safe. I presume that is because the search has timed out.

Note that my current bare URLs search was adopted only when the number of unbracketed, untagged bare URLs dipped below about 110,000. Before that, it timed out, so I used a crude, less complete search which excludes named refs: insource:/\<ref\>https?:\/\/[^ \<\>\{\}+\s*\<\/ref/i]

So Elasticsearch 7 is causing my current search to timeout at less than half the hit count which caused the Elasticsearch 6 to timeout.

What exactly are the upsides of Elasticsearch 7? I see only significantly degraded performance, with no benefits. Have I missed something? BrownHairedGirl (talk) • (contribs) 11:01, 13 September 2022 (UTC)[reply]

Using Elasticsearch 6 blocks the use of PHP 8 (see the task chain), which constitutes a security concern as PHP 7 goes out of support soon. Elasticsearch 6 is also not supported by today's and/or tomorrow's OS vendors, which constitutes its own separate security concern. Nearly all version bumps where the feature set is not advertised widely are due to security at the end of the day. Izno (talk) 15:22, 13 September 2022 (UTC)[reply]

Thanks, @Izno. I accept that security concerns will be a driving factor.

But the result of this security fix is a significant fall in performance. It would be helpful to know what processes are underway to identify and implement measures to offset the performance hit, so that users do not lose functionality. BrownHairedGirl (talk) • (contribs) 15:48, 13 September 2022 (UTC)[reply]

@RKemper (WMF): any chance of an comment on whether there is a process to offset the performance hit?

Some of my other work is badly hit by this. For example, I am cleaning up the remaining bare URLs on some top-level domains. I have already done .pk, .si, .ua, .int and .ie. Now I am back to working on .fr, but since the upgrade to Elasticsearch 7 my search insource:/\<ref( [^\>]*)?\>https?:\/\/[^\/ \<\>\{\}]+?\.fr\/[^ \<\>\{\}]+ *\<\/ref/i times out more often than not. Before the upgrade, it never timed out. BrownHairedGirl (talk) • (contribs) 00:41, 16 September 2022 (UTC)[reply]

Part of the upgrade requires switching traffic to a single cluster while we upgrade the other. At the moment, the search traffic is going to our secondary datacenter (codfw). This leads to higher load on the cluster and higher latency due to traffic between datacenters. I'm not confident that this is the only reason, there might well be use cases where Elasticsearch 7 has lower performances than Elasticsearch 6. But it make sense to wait until the migration is fully completed before investigating this further. You can check the progress on this Phab task: https://phabricator.wikimedia.org/T308676.

GLederrey (WMF) (talk) GLederrey (WMF) (talk) 14:58, 16 September 2022 (UTC)[reply]

After RKemper (WMF)'s helpful comments about the upgrade from Elasticsearch 6.8.23 to Elasticsearch 7.10.2, I did a quick google for docs on changes in functionality. However, all I found was a cluster of pages on the Elasticsearch website which extolled the software's virtues for sysops, such as more compact logfiles. Nothing about users.

Is there any documentation of any changes for users of the search?

For example, I would love the search to support Perl-style shorthand character classes such as \s, \S, \d, and \b. (I have a crush on \b). That would eliminate some tedious conversion and debugging when I take a regex from a Perl script or a C# AWB custom module to use in an insource search (or vice versa), as I often do for sanity checks.

Does the upgrade bring any such changes to the construction and/or reliability of regex searches? --BrownHairedGirl (talk) • (contribs) 07:39, 9 September 2022 (UTC)[reply]

The regex support is actually provided by Lucene, which does not provide full regex support. Elasticsearch documents their regex support for v7 on this documentation page. —TheDJ (talk • contribs) 08:21, 9 September 2022 (UTC)[reply]

Thanks, @TheDJ. That link is very helpful ... unlike the half-arsed version of regex which it implements. BrownHairedGirl (talk) • (contribs) 10:33, 9 September 2022 (UTC)[reply]

I am having a strange problem with one particular table while editing the article Dancing with the Stars (American season 15). It is Dancing with the Stars (American season 15)#Week 6: Country Week. For whatever reason, the bottom section of the table does not display when published, but looks correct when editing. Any assistance would be appreciated, as I have never encountered this problem before. Thank you! Bgsu98 (talk) 20:43, 12 September 2022 (UTC)[reply]

I don't know what the problem is, but I think I found a halfassed solution; not sure it's still displaying properly along the bottom edge of the table. Bgsu98 (talk) 20:51, 12 September 2022 (UTC)[reply]

@Bgsu98: Sortable tables sometimes fail to render properly if the last row is unusual in some sense. I don't know the exact circumstances which can make it fail but a workaround is to add a non-displayed row at the end:

|- style="display:none;"
| colspan="5" | <!-- Non-displayed row to handle limitation ín sortable tables -->

A source comment may prevent users from deleting pointless looking code. PrimeHunter (talk) 21:24, 12 September 2022 (UTC)[reply]

Thank you for the suggestion! 😃 Bgsu98 (talk) 22:52, 12 September 2022 (UTC)[reply]

If that works, then that sounds like someone miscounted rowspans/colspans somewhere higher up in the table. —TheDJ (talk • contribs) 07:20, 13 September 2022 (UTC)[reply]

No, I have encountered it before. It can happen if the last row of a sortable table only has header cells declared in the row itself. Simpler example with rowspan="3" | B3 and rowspan="2" | C2:

A1	A2	A3
B1	B2	B3
C1	C2
D1

It works without sortable:

A1	A2	A3
B1	B2	B3
C1	C2
D1

It works with sortable if a non-displayed row is added at the end and that row has non-header cells:

A1	A2	A3
B1	B2	B3
C1	C2
D1
non-displayed row

PrimeHunter (talk) 13:34, 13 September 2022 (UTC)[reply]

Ah yes, it also happens for incomplete rows yes. Basically, whenever u leave a gap, one way or another, the script has an incomplete amount of cells to work with and the behavior is then undefined. Complete ur table grids ;) —TheDJ (talk • contribs) 14:31, 13 September 2022 (UTC)[reply]

But the grid is complete here. The rowspans in C2 and B3 cover the D row. It seems like a bug or limitation in sortable. PrimeHunter (talk) 15:28, 13 September 2022 (UTC)[reply]

Maybe some kind of Phab ticket should be created here. Even the undefined behavior thing sounds like it could use a fix, i.e. detect invalid rowspan/colspan formatting and do nothing rather than undefined behavior. –Novem Linguae (talk) 17:02, 13 September 2022 (UTC)[reply]

Oh wait, now i get it.. I was thrown off course by the example, as i have sticky headers enabled, which has the same logic applied to all tables as tablesorter, so your 'good example' was also showing wrong for me :)

So to summarize, this situation exists if the the last row contains only header cells, because of previous rows having td cells with rowspans which end in the last row (or rows for potential multiline tfoot). I have a workaround for this, but it's so ugly (over 20 lines of code)... I really wish that it was easier to have a column count of a table. Especially before es6 it's just nuts. I'll work a bit on it the coming days. —TheDJ (talk • contribs) 22:57, 13 September 2022 (UTC)[reply]

Seems like this is the same problem that we discussed here a couple days ago: Wikipedia:Village pump (technical)/Archive 200#Table weirdness (except that with table footers rather than headers). Matma Rex talk 20:28, 14 September 2022 (UTC)[reply]

I was wondering how crazy would the idea of having a section history feature be.

Such feature would only track the history of individual sections, be those in the main namespaces or in the talkspace (topic history) and ideally it could be accessible by the sections' headers, much like the whole page history is accessible by its header.

Considering that in WikiWorld sections are rather brittle and prone to change this idea can sound too unrealistic as I've put it above but maybe it would be more realistic if we just made it possible to filter the page history for individual sections and then work from there? (Section links are already a thing in page history.)

I've found myself many times in need of knowing how some certain sections have changed throughout time in a page. The way I currently achieve this is by checking different versions of the page and continuously scrolling down to the section I need to check, which is cumbersome to say the least. Klein Muçi (talk) 15:20, 13 September 2022 (UTC)[reply]

Not exactly what you're looking for, but worth mentioning: https://chrome.google.com/webstore/detail/who-wrote-that/ekkbnedhfelfaidbpaedaecjiokkionn?hl=en –Novem Linguae (talk) 15:26, 13 September 2022 (UTC)[reply]

• I am not aware of anything that does it, but it certainly could be done by a gadget or user script. I do not volunteer, but it seems simple enough and useful enough that you could probably find a taker at WP:BOTREQ. One possible method would be:

1. make one API call to query the revisions comments (doc here, it should look something like action=query&prop=revisions&titles=(Current page title here)&rvprop=comment{{|}}ids&rvlimit=max). (If max=500 revisions is not enough, multiple API calls might be needed.)
2. filter only the revisions whose comment starts with /* (desired section title here) */
3. return the ids of those and somehow display it to the user - for instance, a list of diffs targeted to the section name. (The super-fancy version would display a page-preview-style box on mouseover, but I have no idea how you would do that stuff.)

Alternatively, one could imagine that the user does not provide a list of section titles, but the script identifies all section titles and groups revisions by that (we need to query all revisions anyway), the user can then use a dropdown menu to pick the section they want.

That edit summary heuristic might not work. It picks up the diffs where an editor clicked on the section link and did not modify the edit summary prefix, so it has both false positives (typically, someone who creates a section would appear under the name of the section before or after it) and false negatives (if someone modifies the edit summary). It is probably enough for most use cases though.

Tigraan^{Click here for my talk page ("private" contact)} 16:01, 13 September 2022 (UTC)[reply]

Tigraan, Novem Linguae, thank you! Actually what I had in mind is exactly what user Tigraan described. Shouldn't a phab-ticket be better than US/R? I feel like this could be common enough to be a native feature request, no? Although WP:US/R would probably provide a faster solution. — Klein Muçi (talk) 21:49, 13 September 2022 (UTC)[reply]

I think this is niche enough that devs would not want to add it to core, so I recommend WP:US/R. I think the algorithm above is simple (easy-ish to code), but will miss a bunch of edits in each section, since any edit can touch any section. Hope that helps. –Novem Linguae (talk) 22:09, 13 September 2022 (UTC)[reply]

Actually did both.
Currently tracked on Phabricator and on WP:US/R as: Wikipedia:User scripts/Requests#Section history
Hope it gets implemented somewhere. :) — Klein Muçi (talk) 09:59, 15 September 2022 (UTC)[reply]

The Beta Feature for DiscussionTools is supposed to get some updates this month. You can see "everything" at these links:

• https://patchdemo.wmflabs.org/wikis/300e52d41c/wiki/Talk:New_York?useskin=vector-2022
• https://patchdemo.wmflabs.org/wikis/300e52d41c/wiki/Talk:New_York?useskin=vector
• https://patchdemo.wmflabs.org/wikis/300e52d41c/wiki/Talk:New_York?useskin=monobook
• https://patchdemo.wmflabs.org/wikis/300e52d41c/wiki/Talk:New_York?useskin=timeless

The bit that will actually reach the Beta Feature is what the team calls "topic containers". It's just the stuff around the ==Section heading==, not the stuff at the top of the page or the stuff in Vector 2022's new Table of Contents. You'll need to login if you want to see the new subscribe button.

I post this here so you'll know what's going on if someone asks you what caused the talk pages to look different. Whatamidoing (WMF) (talk) 22:53, 13 September 2022 (UTC)[reply]

Whatamidoing, put this in Tech News. @Klein Muçi already asked me about this redesign on 19 August, thinking my script was responsible for it. — Alexis Jazz (talk or ping me) 04:33, 14 September 2022 (UTC)[reply]

This has been in Tech/News off and on for about two months already. This particular set of changes is already in the Beta Feature everywhere except enwiki, dewiki, and jawiki at this point. There are two more sets of changes coming up for desktop users.

(I'm in a scheduling meeting right now. It sounds like this change won't happen here until Wednesday, 21 September at the earliest, and the next set has just been delayed until mid-October except for arwiki, huwiki and cswiki.) Whatamidoing (WMF) (talk) 17:01, 14 September 2022 (UTC)[reply]

Whatamidoing, this is only tangentially related to the subject but I had a question that has been bothering me for a while now: Why do we have an inverted kebab menu on the notifications only for it to show the unsubscribe button? I have the impression these kinds of menus are saved for multi-entries dropdowns. There's plenty of room there, why not just have the unsubscribe button directly there instead of hiding it inserted in a cupboard? — Klein Muçi (talk) 09:34, 14 September 2022 (UTC)[reply]

If memory serves, when they made that decision, they were considering the possibility of a second item for the menu (a link to Echo/Notification preferences, maybe?). It hasn't been added, but they didn't go back to change it afterwards. Whatamidoing (WMF) (talk) 17:02, 14 September 2022 (UTC)[reply]

Whatamidoing, I see... I wish that one of the two options you mention was provided already. Maybe when this update goes live. Taking the unsubscribe button out of the cupboard under the stairs looks straightforward and easy enough, even if that's only a temporary solution. — Klein Muçi (talk) 10:43, 15 September 2022 (UTC)[reply]

Sad that this is going to be out without making the headings more accessible, see the task on Phabricator. @Whatamidoing, can you confirm to me that projects that have enabled this by default would not receive this feature in its current state without their explicit approval? stjn 09:31, 19 September 2022 (UTC)[reply]

Stjn, good to hear I'm not alone on this.. "Putting discussion activity inside the header, yet displaying it below it. Great job. Thanks DT."
Needless to say, my script inserts discussion activity after the header. — Alexis Jazz (talk or ping me) 12:12, 19 September 2022 (UTC)[reply]

There is a ratelimit of 20 mails every 24 hours for mailing other users: mw:Manual:$wgRateLimits. This is a reasonably sensible limit for the "user" group. It's probably enough for 99% of users 99% of the time.
Except I just added a feature to my script that allows sending notifications to yourself by mail. While on-wiki notifications often make more sense, some people have a workflow that revolves around email.
But now I'm constantly hitting the rate limit as I'm currently involved in several discussions with a high back-and-forth rate that trigger a mail notification from my script and I wonder how to solve it. To throttle on the script's end seems complicated as I can't predict when the user will go offline. Raising the limit could be an obvious solution, either by raising the limit for mails to self (but MediaWiki doesn't discriminate between mails to others and mails to self) or by raising the general limit for, say, extendedconfirmed. Or maybe there's an obvious solution I'm just not seeing? — Alexis Jazz (talk or ping me) 04:25, 14 September 2022 (UTC)[reply]

You could collect people's emails and send them from toolforge or something, although that's less clean in a sense. Enterprisey (talk!) 05:34, 14 September 2022 (UTC)[reply]

Can you provide more details on your script, and the steps in the scenario? I'm trying to understand if one or both users are using your script, how the email to you is triggered, and which user sends it. The conventional answer is to bundle notifications, but that does require a specific entity to do the bundling—typically a server, as suggested by Enterprisey. isaacl (talk) 05:55, 14 September 2022 (UTC)[reply]

Enterprisey, the script works standalone and isn't meant to be limited to WMF wikis. And collecting personal information like that doesn't feel right either. Also, ToolForge rules disallow it: all network connections must originate from or terminate at Wikimedia Cloud Services. With this, the origin would be a userscript on some personal IP and the connection would terminate at some mailserver. It's also very complicated (or downright disallowed) by the rules regarding user information. "Hash, encrypt, or otherwise properly secure any Private Information you store" is a problem when you need to use said information and as you may "Not share any Private Information outside of your Cloud Services Project" I don't think you can share the mail address with the mail server.
Isaacl, it's Factotum and it allows you to subscribe to sections and get notifications when someone posts a new comment. For example, I got a notification about your post here as I'm subscribed to this section. Notifications do get bundled (if 50 new comments are found you get only 1 mail), but the script checks every N minutes+whenever you Special:Watchlist for new comments so you could still hit the limit without overly extreme behavior. — Alexis Jazz (talk or ping me) 07:15, 14 September 2022 (UTC)[reply]

The conventional approach used by other messaging platforms is to send out an email once per some period (typically daily, though it could be shorter). Time-based limits tend to work better with email-based workflows, which often involve setting aside scheduled time to manage email. isaacl (talk) 15:24, 14 September 2022 (UTC)[reply]

"Bundling" email notifications so at max N are sent in any given period could be an option (perhaps a setting that users can turn on if they know they'll be involved in fast-moving discussions). I do not think that raising the rate limit is in any way a good idea. firefly ( t · c ) 08:50, 14 September 2022 (UTC)[reply]

Would it be possible to have a seperate limit for emails that you send to yourself? This IMO has very little or no avenues for abuse as you couldn't spam someone else and the only thing that may be an issue is if the operation is expensive and it being called rapidly. This could be addressed by having a smaller timespan but a lower maximum, such as 10 emails to yourself every 60 minutes. That would help prevent rapid bursts that could cause server lag, but would make using this script possible. Dreamy Jazz ^{talk to me | my contributions} 09:04, 14 September 2022 (UTC)[reply]

I think the solution here is fairly simple — don't do that (also, User:Alexis Jazz/Factotum#Feature comparison matrix, "Sigh, the free bug tracker that anybody nobody can edit." - you know you can just request a project be created for you... right?) — TheresNoTime (talk • they/them) 10:02, 14 September 2022 (UTC)[reply]

TheresNoTime, I'm in no way a semantics professor but isn't it a bit "strange" to state in the same sentence to not do something and also "criticize" someone for saying that they are not allowed to do something? :P I mean, I get that they are different subjects but to my eyes it seemed rather contradictory/funny. :P — Klein Muçi (talk) 10:11, 14 September 2022 (UTC)[reply]

TheresNoTime, you know you can just request a project be created for you... right? No doubt, but the Wikipedia slogan refers to the fact that anybody can edit it without asking for permission. You may get reverted, but you can edit. Even the creation of new articles is possible without permission, all you need for that is autoconfirmed which is granted automatically when you meet the requirements.
Not so on Phabricator. You can request the creation of a project, but you can't do it yourself. I can mail the Encyclopædia Britannica staff to request a correction, that doesn't make it an "encyclopedia anybody can edit".
The "don't do that" advice is universally true. Wikipedia not loading? So don't load Wikipedia. Editor broken? So stop editing articles. Computer broken? So don't use the computer. Stove not working? Don't fix the stove, get takeout.
Xaosflux, If you want emails for changes to pages on your watchlist, you can just enable "Email me when a page or a file on my watchlist is changed" in Special:Preferences.
My script mails you links that scroll to the new comment and only mails for comments in subscribed sections so it's a bit different. — Alexis Jazz (talk or ping me) 13:55, 14 September 2022 (UTC)[reply]

The humorous tone in which my comment was written in did not land, apologies — applying the "anyone can edit" slogan to things which aren't Wikipedia is a bit of a stretch... though I would say that there's plenty here that can't be edited without asking for permission (the Main Page for example..)!

To atone for my poor attempt at humour earlier, I'd be more than happy to file a task and look into separating out the email rate limit for self — TheresNoTime (talk • they/them) 14:03, 14 September 2022 (UTC)[reply]

TheresNoTime, I'm in no way an ethics professor but I really liked the courtesy you expressed. :) Cheers! — Klein Muçi (talk) 14:23, 14 September 2022 (UTC)[reply]

@Klein Muçi forgot to say thanks for this, and it's good to hear — it's something I've been trying to improve... it's all too easy to be hot-headed when you're communicating over the medium of text. Never worth it though! — TheresNoTime (talk • they/them) 15:12, 14 September 2022 (UTC)[reply]

TheresNoTime, I'm sorry I was mistaken by your text above. Thank you for the kindness! — Klein Muçi (talk) 23:12, 14 September 2022 (UTC)[reply]

TheresNoTime,
The humorous tone in which my comment was written in did not land, apologies
I didn't realize you were jesting! Your comment makes much more sense reading it in that light. :-)
applying the "anyone can edit" slogan to things which aren't Wikipedia is a bit of a stretch...
Perhaps, but I think it goes against the spirit of Wikimedia in general.
though I would say that there's plenty here that can't be edited without asking for permission (the Main Page for example..)!
True, but that's generally for actions that are sensitive to abuse. Creating a project on Phabricator isn't a spam magnet. I wouldn't even mind some requirement, like needing to be registered for a month and having posted 10 comments or something, but it shouldn't require human approval. Especially now that the entire TechConductCommittee is stonewalling me..
I'd be more than happy to file a task and look into separating out the email rate limit for self
That would be super awesome! A shorter limit like 10/hour as Dreamy Jazz suggested would work much better. I mailed myself a bunch of times as part of testing and now I keep running into the limit partly because of tests I performed many hours ago that won't expire until tomorrow. — Alexis Jazz (talk or ping me) 14:31, 14 September 2022 (UTC)[reply]

@Alexis Jazz: I've logged T317770 — if/when the rate limits are split, a more permissive limit can be agreed upon for emailself — TheresNoTime (talk • they/them) 14:57, 14 September 2022 (UTC)[reply]

“isn't a spam magnet” you’d think…unfortunately phabricator (and before bugzilla) have been high rate spammed in all kinds of ways and when it happens it’s VERY disruptive. Because the platforms aren’t revision based, the vandalism is also harder to undo than on Mediawiki. —TheDJ (talk • contribs) 18:28, 14 September 2022 (UTC)[reply]

TheDJ, I know everything everywhere gets spammed, but I'd be surprised if project creation specifically would be a spam magnet. I'd expect the majority of spambots on Phabricator to be generic, randomly filling out forms in hopes of spamming their fake Viagra. I suspect that requiring a confirmed mail address or having some number of edits with the associated Wikimedia unified account would cancel the vast majority of the spam.
Even if that wouldn't be enough, I'm in the "Trusted-Contributors" group but apparently that makes me no less of a spam risk. — Alexis Jazz (talk or ping me) 19:46, 14 September 2022 (UTC)[reply]

If you want emails for changes to pages on your watchlist, you can just enable Email me when a page or a file on my watchlist is changed in Special:Preferences. — xaosflux ^Talk 13:45, 14 September 2022 (UTC)[reply]

The page preview for Remember (Walking in the Sand) has missing text. In the first sentence, the "(Walking in the Sand)" does not appear, making the sentence appear illogical. Note that it does appear properly in WP:POPUPS, which I have enabled on my account; I noticed the bug while I was browsing logged out. Home Lander (talk) 14:28, 14 September 2022 (UTC)[reply]

Is this a bug? It seems to be intended that text enclosed in parentheses doesn't display in preview mode; it's certainly been that way as long as I've been browsing as an IP. In this particular case it causes a problem, but usually it just eliminates unnecessary detail from the quick preview (like the birth/death dates at Alexander Gardner or the pronunciation details from Himalayas). 199.208.172.35 (talk) 14:49, 14 September 2022 (UTC)[reply]

@Home Lander: seems like this is related to the undesirable handling of parentheses described in phab:T263932, you can update that to include more use-cases such as titles that have literal parentheses in them. — xaosflux ^Talk 15:10, 14 September 2022 (UTC)[reply]

First time I've heard of this - so I tried logging out, going to Remember (Walking in the Sand), clicking the "Edit" tab and then the Show preview button. I see text in parentheses, no problem. --Redrose64 🌹 (talk) 10:32, 18 September 2022 (UTC)[reply]

@Redrose64 that's not the "preview" they are talking about. Log out (or just open a private browsing tab) to this page, and mouse-over the page link; look at the pop-up preview. — xaosflux ^Talk 11:41, 18 September 2022 (UTC)[reply]

Would that be Navigation popups: article previews and editing functions pop up when hovering over links? --Redrose64 🌹 (talk) 17:14, 18 September 2022 (UTC)[reply]

@Redrose64 that one is mw:Extension:Popups. — xaosflux ^Talk 18:30, 18 September 2022 (UTC)[reply]

The field "Registered electors" need to be added to Vav Assembly constituency#2017 Vidhan Sabha so that it looks similar to Abdasa_Assembly_constituency#2017_Vidhan_Sabha. I know how to do this manually. I would like to do this on AWB since there are hundreds of constituency pages that would require same manual edit to add the parameter.

Can someone guide me with the steps to do this? Venkat TL (talk) 15:55, 14 September 2022 (UTC)[reply]

@Venkat TL would you provide a single diff of doing the change manually as an example? — xaosflux ^Talk 17:06, 14 September 2022 (UTC)[reply]

@Xaosflux here is an example edit Special:Diff/1110293677 of doing this on Vansda Assembly constituency. Need to insert a line in the middle of the template. Venkat TL (talk) 17:24, 14 September 2022 (UTC)[reply]

@Venkat TL:Your diff adds a template call, not a parameter. It adds a pointless table row with no information unless a number is included at reg. electors. If you plan to manully add the number later then it's only a little harder to add the whole call at that time. Your diff adds the call right before {{Election box end}} but your example Abdasa Assembly constituency#2017 Vidhan Sabha has it before {{Election box hold with party link}}. You added it to the 2017 section but not the 2012 section and it's already in the 2022 section. Which sections do you want it in? You can make a much clearer request at Wikipedia:AutoWikiBrowser/Tasks. If you have a data source for reg. electors then include it in the request. Somebody may make the edits including the number. There are ways to do that with AWB so you don't have to manually edit all the articles anyway. PrimeHunter (talk) 17:53, 14 September 2022 (UTC)[reply]

@PrimeHunter thanks for the reply. Yes, the intention is to add the registered Voter data into that table row eventually. The 2017 and 2022 tables can have the data from the Total voters table at List_of_constituencies_of_the_Gujarat_Legislative_Assembly#List_of_Assembly_Constituencies. The reg. electors row needs to be in the lower half of the table immediately after {{Election box turnout}} and before {{Election box hold with party link}}. It would be great if this can be done using the tool, would save a lot of time. Manually adding the row and data, would be the last option. Also ping @MPGuy2824 Venkat TL (talk) 18:01, 14 September 2022 (UTC)[reply]

@Venkat TL: As I said, you can make a request at Wikipedia:AutoWikiBrowser/Tasks. Having the data in a page with a link and therefore exact name of the article (except for a few redirects) is great. That can definitely be automated. PrimeHunter (talk) 18:09, 14 September 2022 (UTC)[reply]

@PrimeHunter I have requested it at Wikipedia:AutoWikiBrowser/Tasks#Reg._electors_row_addition_in_constituency_articles. Venkat TL (talk) 18:23, 14 September 2022 (UTC)[reply]

Wikipedia:EditNoticesOnMobile has been release for the final wave, all editors. If there are any issues please report at Wikipedia_talk:EditNoticesOnMobile#Final_wave. If any urgent breaking thing has happened, any admin can revert the last update in MediaWiki:Gadgets-definition. — xaosflux ^Talk 19:02, 14 September 2022 (UTC)[reply]

The infobox map in Italia Conti Academy of Theatre Arts shews it as being in central London, but according to the rest of the infobox it's in Guildford. I can't see anything in the infobox to control the map. Does anyone know how to stop it being so wrong? Thanks, DuncanHill (talk) 19:26, 14 September 2022 (UTC)[reply]

@DuncanHill: Click "Wikidata item" under "Tools" in the left pane to see the source [1] of the coordinates. Google Street View shows a sign there saying "THE ITALIA CONTI ACADEMY OF THEATRE ARTS". The article mentions several associated locations including Italia Conti Associates Guildford. It appears from Italia Conti Academy of Theatre Arts#Woking, Surrey (New Building) that the main location is in Woking since August 2022. The offical website says 47 Church Street West, Woking at [2] and [3]. Maybe Wikidata should be updated but not to Guildford. PrimeHunter (talk) 19:55, 14 September 2022 (UTC)[reply]

Does anyone know where I can find the source code for the code that generates the directory on category pages? I’m mulling trying to fix it for Chinese (for Chinese, using the first character as a head is unhelpful, is not traditional, and makes things difficult to find because things are essentially sorted in random order). Thanks!—al12si (talk) 00:09, 15 September 2022 (UTC)[reply]

@Al12si: MediaWiki is pretty complex. If you have to ask where code is and choose to ask here then I'm not sure you should be trying to submit MediaWiki patches. I suggest a feature request instead, or maybe phab:T170049 is what you want. PrimeHunter (talk) 02:28, 15 September 2022 (UTC)[reply]

@PrimeHunter: Ok, in that case I’ll grab a copy of the software, install it somewhere and find out myself where this is done and try to fix it. I’ve already got the logic figured out and am doing this on my own site. If I can fix it I’ll track down a way to submit a patch. Thanks.—al12si (talk) 02:46, 15 September 2022 (UTC)[reply]

PS: @PrimeHunter: I checked out phab:T170049; the proposal is counter-productive. Not only does it make things worse for me (and the Wikipedia I’m now active in), it actually makes things worse even for English speakers because if implemented, Japanese terms would be lumped with Chinese terms. The idea that Mandarin is a suitable “standard” pronunciation is a misguided idea and should be always treated as a red flag.—al12si (talk) 04:35, 15 September 2022 (UTC)[reply]

@Al12si: There's also some guidance about the category collation setting in the manual namespace on MediaWiki. Graham87 03:17, 15 September 2022 (UTC)[reply]

@Graham87: Thank you. I’ll suggest my active Wikipedia’s admins to try using uca-default (if that’s not the current setting) and see if it improves things. My suspicion is that categories still won’t be grouped correctly though; I know a certain very-well-known university press doesn’t understand how entries in an index are supposed to be grouped together; this seems to be very obscure knwoledge outside the CJK world.—al12si (talk) 04:47, 15 September 2022 (UTC)[reply]

Al12si, when categorizing a page you should do so like [[Category:Cars|SORTKEY]]. See mw:Help:Categories. — Alexis Jazz (talk or ping me) 06:39, 15 September 2022 (UTC)[reply]

@Alexis Jazz: Thank you; I have forgotten about this. However, I don’t think this will work for article titles. The category pages currently group article titles according to the first character in the title; if the titles start with kanji this will result in a proliferation of headings (that are unhelpful and often not even sorted correctly). This is not how we do it and this is what I’m thinking of trying to fix.—al12si (talk) 07:12, 15 September 2022 (UTC)[reply]

Looks like mediawiki/includes/CategoryViewer.php. Tip: To figure out what file is generating a piece of code, go find some unique string on the output page, then use your code editor (such as VS Code) to do an all files search. I searched for "Pages in category", then found out this is called "category_header", then found CategoryViewer.php. –Novem Linguae (talk) 11:08, 15 September 2022 (UTC)[reply]

You can also use uselang=qqx to find the name of system messages, e.g. [4] to find "category_header". PrimeHunter (talk) 21:08, 15 September 2022 (UTC)[reply]

Hello!

Links that have forms.gle in them are globally blocked from being posted anywhere as far as I understand. Can someone tell me where this block is coming from and possibly why? I checked the spam blacklist in Meta but I couldn't find anything relevant there. - Klein Muçi (talk) 11:08, 15 September 2022 (UTC)[reply]

Please post an example. You can put a URL in nowiki or omit the leading http/https and the // following. Johnuniq (talk) 11:17, 15 September 2022 (UTC)[reply]

It's globally blacklisted. The log is at m:Spam_blacklist/Log/2019/08. Search for "\bforms\.gle\b". With most links of this type you can use the proper URL instead of the shortener, but I don't know for sure about this one. -- zzuuzz ^(talk) 11:19, 15 September 2022 (UTC)[reply]

Google forms has a long URL. forms.gle is shortened. 0xDeadbeef 11:33, 15 September 2022 (UTC)[reply]

Ah, I see. I wasn't fully aware I was dealing with a shortened URL. So in my homewiki one user was trying to post a Google Form in our VP for a wiki-edit-a-thon. But they notified me that they were being stopped from doing that. I thought I'd try it as admins are usually excluded from edit filters but I quickly noticed that the block was global and after failing at Meta, I came here. I hadn't noticed that the URL was shortened. If I had, I'd be almost sure it would have to do with that. I'll tell the said user to use the full URL. Thank you! — Klein Muçi (talk) 11:45, 15 September 2022 (UTC)[reply]

Klein Muçi, if you give me an example of a shortened URL and the equivalent long URL I can probably add it to Factotum. (it already does this for youtu.be which is also blacklisted) — Alexis Jazz (talk or ping me) 12:56, 15 September 2022 (UTC)[reply]

Alexis Jazz, in this case:
Short URL: https://forms.gle/t1M6XLkgiHTL4XQW6
Long URL: https://docs.google.com/forms/d/e/1FAIpQLSdLK83vxevNXMPxfDKqZbDBb9VHBGGa6B-mwKIBcHalwSnNTw/closedform
I'll keep that in mind for other cases. Thanks for the initiative! :) — Klein Muçi (talk) 13:23, 15 September 2022 (UTC)[reply]

Klein Muçi, unfortunately there's no way to convert that. I'll just automatically nowiki it so it doesn't trigger the spamblacklist anymore. — Alexis Jazz (talk or ping me) 14:43, 15 September 2022 (UTC)[reply]

Alexis Jazz, yeah, I thought so. Are we sure that is a behavior a user expects? I mean, wouldn't it be strange for the user if they randomly got some URLs nowiki-ed, without any explanation? (As opposed to having an error message explaining that what you're trying to do is "illegal".) (Wouldn't it also be showing the way how to "circumvent" the limitation?) I believe an opt-in should be better than having it default behavior but you know it better. — Klein Muçi (talk) 15:16, 15 September 2022 (UTC)[reply]

Klein Muçi, being told it's illegal without being told WHY and HOW to fix it is next to useless and the user will likely give up. (or figure out a similar workaround themselves) I've been puzzled by this before I knew. This way a WikiGnome or bot can fix it, or you can select+right click the link or copy-paste it to your address bar to visit it. — Alexis Jazz (talk or ping me) 19:29, 15 September 2022 (UTC)[reply]

Alexis Jazz, I do agree on the missing WHY/HOW part but that's a problem that theoretically can be solved with the message. Having a link appear nowikied without knowing WHY can be confusing as well (that's why I thought about the opt-in part) but I'm supposing that can be solved with documentation so... — Klein Muçi (talk) 22:21, 15 September 2022 (UTC)[reply]

• FWIW, phab:T313106 is being discussed about allowing sysops to add spamblacklist entries by default, phab:T313107 is about bots - and communities can also get sboverride added locally if needed (probably best to see where the default tasks go first). — xaosflux ^Talk 13:50, 15 September 2022 (UTC)[reply]

I presume if it's a static IP that they won't be able to register. But what happens if it's dynamie? Doug Weller talk 15:24, 15 September 2022 (UTC)[reply]

@Doug Weller seems a little bit WP:BEANSy. It sort of depends in what order things occur, and how cookies are handled by the client. If an IP is blocked, then the next time someone visits us they have a new IP - we usually won't know they are the same person and the block won't apply. There are all sorts of other situations that could overlap: if user accounts are involved, if someone visits while they are blocked, and with range blocks. — xaosflux ^Talk 17:23, 15 September 2022 (UTC)[reply]

@Xaosflux more or less what I assumed. I wonder how often it happens that an editor escapes an IP block. Doug Weller talk 17:33, 15 September 2022 (UTC)[reply]

Not really BEANSy, though, because this grew out of a RW situation with a temp-blocked, non-vandal IP user, to whom I recommended registering for an account (diff ). But then on second thought, I reverted myself (diff ), considering the possible socky look of following that advice. The underlying question in this story, is: "Should one avoid recommending registration to a temp blocked, good-faith user?" No guideline says not to, and neither does {{Register}}. Fuller backstory details here. Mathglot (talk) 00:42, 16 September 2022 (UTC)[reply]

@Doug Weller: When I shut my Wifi off or get away from the Wifi's signal, my cell phone has a dynamic IP that's currently under a rangeblock. If I try to register an account, I receive "Account creation error" followed by standard templates that the IP address or range is currently blocked; and shows who issued the block and the reason (currently there are global and local blocks on the range I'm assigned at the moment). Home Lander (talk) 13:51, 16 September 2022 (UTC)[reply]

Resolved

 – This bug was resolved upstream. — xaosflux ^Talk 13:56, 16 September 2022 (UTC)[reply]

Was: Discussion page TOCs might be disappearing soon

Just a heads up. This issue recently affected Wiktionary, and is also affecting other Wikimedia sites upgraded to 1.40.0-wmf.1, e.g. d:Wikidata:Project chat (before vs after), s:Wikisource:Scriptorium (before vs after). It's apparent that the WMF does not consider this a blocker to upgrading. OTOH, maybe they'll fix it first and EnWP will be spared. 98.170.164.88 (talk) 16:42, 15 September 2022 (UTC)[reply]

• It appears that multiple devs are actively working on this already, including working on backports. — xaosflux ^Talk 17:26, 15 September 2022 (UTC)[reply]

^ This is what I just saw on a black screen on trying to open any Wikipedia links. What went wrong? —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:44, 15 September 2022 (UTC)[reply]

@CX Zoom: See Phabricator. I got this as well. 0xDeadbeef 16:45, 15 September 2022 (UTC)[reply]

Thanks! —CX Zoom[he/him] ^{(let's talk • {C•X})} 16:46, 15 September 2022 (UTC)[reply]

Probably because it's WP:THURSDAY. I got the error for about 5 minutes. Jip Orlando (talk) 16:48, 15 September 2022 (UTC)[reply]

This wasn't caused by the train (timestamps don't match). There was an incident with Thanos at the same time as the outage (see #wikimedia-sre log starting 16:39:49), but it isn't really clear how that could have caused this. Zabe (talk) 22:12, 15 September 2022 (UTC)[reply]

Hi all, Volker E. here, I'm Design Lead at the Wikimedia Foundation Product Design team and would like to provide an update to the external link icon discussion earlier on WP:VPR.

When rolled out initially, we didn't catch pixel issues on lo-dpi screens. Additionally, the old icon version featured long-standing usability issue: it was not sizing up when users increase text zoom (a common accessibility feature in use) in their browser preferences. We've seen your request on VPR and have recognized the problem statement. We then fixed the technical issues being behind vast majority of replies. And we've taken inputs by volunteers to improve the icon for better recognizability from the original proposal. For the subsequent changes on the icon itself and for future icon rollouts, we've set out a longer testing window with more explicit testing strategy.

Our goal has been to provide a unified icon collection with quality characteristics for several years now. Among the characteristics are

• Simplifying by reducing to the essential form – the lesser the details on such small icon size, the better they are recognized by the users.
• Making the icons as universally recognizable as possible - Users switching from mobile to desktop should be shown the same icons for the same thing. The mobile frontend (Minerva Neue skin) has been featuring the proposed new icon for over a year already.

Other high visibility icons, such as 'search', 'user avatar', 'watchlist', 'edit' (pencil) or the 'language' icon were changed in the past accordingly. Thanks for your attention. Do you perhaps have any questions? – Volker E. (WMF) (talk) 20:31, 15 September 2022 (UTC)[reply]

Yes. To what do you ascribe the current situation? Do you feel that WMF has sufficient staff to qa software before release? Was this some kind of unforeseeable glitch? Seems to me like a pre-release targeting only a small percentage of users, or perhaps a Beta with opt-in (possibly pre-opted in by selected tester-users: count me in, if you like) might catch things like this before general release. Might as well take advantage of all the willing, unpaid talent around here. Mathglot (talk) 00:51, 16 September 2022 (UTC)[reply]

Ascribing the situation to a combination of shortcomings to be honest. Situative we've been doing last minute changes to the icon before the new MediaWiki release and therefore and because of not having access to a lo DPI environment at that point in time, the icon didn't meet the quality criteria on these environments.

With this in mind and our normal process, we should provide enough time to test on beta wiki and also for Quality Assurance testers and volunteers to provide us early enough with needed feedback. Thanks for offering your help, checking your user workflows from time to time on Beta could help us, specifically with big software releases. – Volker E. (WMF) (talk) 03:15, 17 September 2022 (UTC)[reply]

I get this error when I created and every time I've saved while editing wp:EWN#User:49.178.160.86 reported by User:Adakiko (Result: ) (likely heading change if resolved) This does not appear to result in anything obviously out of place or displaying after the save. All the links and diffs seem to work. Using Firefox 104.0.2 (64-bit) on Win10 pro64 OSbuild 19043.2006

https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Edit_warring#User%3A49.178.160.86_reported_by_User%3AAdakiko_%28Result%3A_%29 line 10 > injectedScript at line 236: URIError: malformed URI sequence

Not sure where line 10 is. This problem seems unrelated with these archived discussions:

• Archive 139 Mobile view
• Archive 190 Error preventing edit

Cheers Adakiko (talk) 22:34, 15 September 2022 (UTC)[reply]

@Adakiko in User:Adakiko/common.js you are importing a personal userscript, which is importing another one, which is importing another one. Try turning that off and see if your problem resolves first. — xaosflux ^Talk 13:02, 16 September 2022 (UTC)[reply]

Hi, Browser notes states "Linux ... Dillo, ... Cookies are tricky, so logging in is tricky".

Indicates that login with Dillo should be possible. (Interesting style of documentation.)

The cookiesrc file here has this line.
wikipedia.org  ACCEPT

Yet login fails with notice "There seems to be a problem with your login session ...". If someone who's succeeded to configure cookies can explain, that will be very helpful. Thx.

Background
For several years I've used Firefox in Debian. Recently, probably since an upgrade, Firefox crashes frequently reporting "channel error". A documented bug.

This afternoon information for two uploaded images was almost complete when Firefox vanished from the screen. Troubleshooting Firefox will be a goose chase which may never succeed. At this rate the project may never be completed. If Dillo can work, good. It's fast. It isn't bogged with JavaScript.

Thx, ... PeterEasthope (talk) 00:21, 16 September 2022 (UTC)[reply]

Update
In ~/.dillo/cookiesrc revised
wikipedia.org  ACCEPT
to
.org  ACCEPT
Now I can log in.  =8~)  Regards ... PeterEasthope (talk) 14:25, 16 September 2022 (UTC)[reply]

@PeterEasthope you may also need wikimedia.org for certain functions (if you don't want to do the entire TLD). — xaosflux ^Talk 14:37, 16 September 2022 (UTC)[reply]

Noted. ".org" may suffice and can investigate the more specific domains. Appropriate documentation for Dillo still advisable. Thanks, ... PeterEasthope (talk) 22:26, 16 September 2022 (UTC)[reply]

Resolved

 – Browser extension was interfering with editing. — xaosflux ^Talk 13:48, 16 September 2022 (UTC)[reply]

I've noticed in recent edits double square bracket notation has suddenly been changed to single square brackets, plus the suffix "-en" in the link text. For example [ [ foo | bar ] ] (without the spaces) changes to [foo|bar-en]. I type the double square brackets and when I click preview, it changes to this weird new markup. The contents of nowiki tags, transclusions of the {{brackets}} template, square brackets entered as HTML entities, and even old versions of pages (!) are not immune. This is very surprising and undesirable behaviour. What is going on? Hairy Dude (talk) 11:14, 16 September 2022 (UTC)[reply]

• This change is not merely cosmetic. The weird markup doesn't work, so it is breaking many links on the page when I preview the page before publishing (i.e. every time, since I have the "show preview on first edit" preference enabled). It also makes pages flatly incorrect, for example Help:Link. Hairy Dude (talk) 12:24, 16 September 2022 (UTC)[reply]
  • Okay, this is really weird. I'm seeing this behaviour on my desktop computer (Firefox 104.0.2 on Windows 10) but not my phone (Firefox 104.2.0 on Android 13, similarly yesterday's nightly build). Hairy Dude (talk) 12:42, 16 September 2022 (UTC)[reply]

    • Tests:

      Test: bar (reply tool)

      Test 2: bar (wikieditor)

      Test 3: bar (visual editor)

@Hairy Dude: I haven't been able to reproduce this yet, can you please give exact step-by-step directions to do this (perhaps do it in a clean user sandbox as well). Please note which editor you are using as well. — xaosflux ^Talk 12:52, 16 September 2022 (UTC)[reply]

I don't think this is the issue, but you have User:Dr pda/prosesize.js imported in to your monobook.js file, which says not to load it, directing someone that wants to use it to use the Gadget version instead. — xaosflux ^Talk 12:55, 16 September 2022 (UTC)[reply]

I've turned some Firefox extensions off and on and it seems like it's caused by Consent-O-Matic. :( Hairy Dude (talk) 13:43, 16 September 2022 (UTC)[reply]

Thank you for the udpate, looks like we can say this isn't us. — xaosflux ^Talk 13:48, 16 September 2022 (UTC)[reply]

I saw another report at Wikipedia:Help desk#single-bracket wikilinks with '-en' suffix that can't be edited? I have added Consent-O-Matic to Wikipedia:Browser notes#Unwanted effects.[5] PrimeHunter (talk) 13:17, 19 September 2022 (UTC)[reply]

Resolved

 – Resolved on source wiki. — xaosflux ^Talk 14:09, 16 September 2022 (UTC)[reply]

Hello! So over on Meta I have this issue where I"m currently subscribed to Meta:Steward requests/global because I replied to a report of a user saying that i agree that they should be locked. However since i don't want to continue receiving notifications whenever someone reports a user there, I try to click "Unsubscribe" but it says that it fails to unsubscribe. So now I'm stuck subscribed to that. Anyone know of a fix? (if this isn't the right place to ask this please direct me where to go I don't want to constantly see notifications for that). ― Blaze Wolf^Talk_{Blaze Wolf#6545} 13:16, 16 September 2022 (UTC)[reply]

@Blaze Wolf go to meta:Special:TopicSubscriptions and you should be able to delete it. — xaosflux ^Talk 13:46, 16 September 2022 (UTC)[reply]

Thanks! That worked! ― Blaze Wolf^Talk_{Blaze Wolf#6545} 14:04, 16 September 2022 (UTC)[reply]

The problem was also reported as T318028. Matma Rex talk 16:54, 18 September 2022 (UTC)[reply]

Since this edit (12:09, 12 September 2022‎) it frequently happens that Firefox displays that the Internet connection is lost when I click on preview and I have to press the back button a few times until it works again.

However, my Internet connection did not fail and all other websites are working fine. It's a problem because it can happen that I lose all the changes I've made – in the example linked above nearly everything was still in the textbox that I entered before this happened, but now it happened again and I lost all the many changes I've made.

Is this happening to other people too and what could the cause for that be? For the reason just explained, this can be very problematic, I was just done with some copyediting changes and now I have to do them all again.

I don't think this ever happened before and now it does so frequently. Prototyperspective (talk) 22:39, 16 September 2022 (UTC)[reply]

It happens for me, and I use Safari. Imzadi 1979 → 01:57, 17 September 2022 (UTC)[reply]

I've been having this problem sporadically for two to three weeks now. It is terribly annoying. I've been wondering if was just me. If I get it again, I will copy and paste the error message; it's something about the certificate not being valid, but that could just be the browser trying to figure out some unusual situation. – Jonesey95 (talk) 06:13, 17 September 2022 (UTC)[reply]

I just got the error when trying to save an edit:

Secure Connection Failed

An error occurred during a connection to en.wikipedia.org.

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

I am using the latest version of Firefox on Mac OS, with Vector legacy as my editor. This can happen when I click Preview or Publish. It does not happen every time. If I click the "Try Again" button in the browser window (a Firefox button), it usually works. – Jonesey95 (talk) 14:30, 17 September 2022 (UTC)[reply]

Is there a proper way to add content, or search words, to a redirect to draw better hits to it in a search? The intent is to add language that searchers might use so the redirect helps get them to the right place. For example, I added content to the redirect P.M.G.O. Form 1 to add additional possible search content to it. Is this a good way to handle this? Semper Fi! FieldMarine (talk) 14:42, 17 September 2022 (UTC)[reply]

@FieldMarine: Non-redirect text of redirect pages cannot be searched or influence search results as far as I know. mw:Help:CirrusSearch#Full text search says: "all the words in the non-redirect pages are stored in the search database". You have to make more redirects or add content to the target. PrimeHunter (talk) 20:51, 17 September 2022 (UTC)[reply]

I want to know if there are any uses of Template:Infobox language with the following details:

• Each of the creator and settings is either absent or blank
• The signers parameter has a non-blank value
• The familycolor is one of conlang, artificial, constructed or constructed language.

Animal lover |666| 17:24, 17 September 2022 (UTC)[reply]

You should add a language to the template that adds the template to a category depending on whether these conditions are met or not. Ruslik_Zero 19:21, 17 September 2022 (UTC)[reply]

A tracking category needs a good reason. The search hastemplate:"Infobox language" insource:/signers *=/ only gives two results so you can just examine them manually. PrimeHunter (talk) 20:36, 17 September 2022 (UTC)[reply]

Thanks. The answer to my original question is no, as I originally suspected. This is relevant because I'm trying to convert the template to Lua, and I saw what I thought was an optimization for wikicode which would have made the Lua more complicated if the answer to my question was yes; in short, a result from a boolean test done at one part of a template can't be used in an other part and the test must ne redone, while Lua functions don't have that issue. Animal lover |666| 08:04, 18 September 2022 (UTC)[reply]

Some templates call a core subtemplate with the result of oprations which would have to be redone otherwise. PrimeHunter (talk) 12:06, 18 September 2022 (UTC)[reply]

I have made too many edits for XTools to show anymore - when this happened previously somebody at WMF Labs tweaked something. Can the same happen again please? GiantSnowman 19:22, 17 September 2022 (UTC)[reply]

Hey GiantSnowman. I filed a phab ticket for you. This is probably the quickest way to get the attention of a tool's developers. There's a spot on phab to add tags such as "xtools" and that will email everyone that has listed themselves as a watcher of that tag, and usually a tool's developers do this. Hope that helps. –Novem Linguae (talk) 20:51, 17 September 2022 (UTC)[reply]

Thanks for that, appreciate it! GiantSnowman 21:16, 17 September 2022 (UTC)[reply]

Unable to edit the league table for 2022–23 National League 2 East. When I attempt an edit, the league table for 2022–23 National League 2 North is in the template. Would appreciate some help as I am unable to work out where I have gone wrong. Jowaninpensans (talk) 20:57, 17 September 2022 (UTC)[reply]

@Jowaninpensans: I have fixed the page name in the watch/edit/discuss links made by the template.[6] I clicked the "Edit" tab to edit the template when the links didn't work. PrimeHunter (talk) 21:12, 17 September 2022 (UTC)[reply]

This is something that should be picked up by Wikipedia:Database reports/Invalid Navbar links, but it's not - I think because it uses manually-constructed links for edit etc., rather than a {{navbar}}. --Redrose64 🌹 (talk) 16:43, 18 September 2022 (UTC)[reply]

Of seven types of message box, all are visible both from desktop or mobile view, except for {{tmbox}}, which is invisible on mobile. Your feedback would be appreciated at Template talk:Mbox#Tmboxes not visible on mobile (all other mboxes are). Mathglot (talk) 06:46, 18 September 2022 (UTC)[reply]

xaoxflux responded (thanks!) at the link. Mathglot (talk) 08:46, 18 September 2022 (UTC)[reply]

Note: I've created {{Tmboxw}} as a temporary workaround for this problem until T257394 is resolved. Please add bugs, concerns, or other comments at Template talk:Tmboxw. Thanks, Mathglot (talk) 03:38, 19 September 2022 (UTC)[reply]

Resolved

- FlightTime (open channel) 18:38, 18 September 2022 (UTC) [reply]

I'm wondering if I add a page to my watchlist and set it to auto-expire in one month, then I copy/paste from Special:EditWatchlist/raw to my secondary account, does the time factor move with the entry or are the timed entries now semi-permanent and now need to be removed manually? - FlightTime (open channel) 15:18, 18 September 2022 (UTC)[reply]

@FlightTime: raw doesn't yet support expiration management, see phab:T259863 for the feature request. So if you just bring those over like you described they will be of the non-expiring variety. — xaosflux ^Talk 15:23, 18 September 2022 (UTC)[reply]

@Xaosflux: Thank you. I kinda figured that. (pardon me for starting a sentence with "And") And thank you for what you do, it's a real comfort to see your username all over - FlightTime (open channel) 15:37, 18 September 2022 (UTC)[reply]

Hi, after editing of a talk page (e.g., the talk page at Talk:Affine_space#Definitely_not_right) and when we want to publish these edits, we should click the blue button "Publish changes". But if we double click that button instead of a single click, the edits will publish but we redirect to page Edit conflict: Talk:Affine space.

This scenario is not correct, i.e., double clicking should not cause any "edit conflict". So please correct that bug. Hooman Mallahzadeh (talk) 04:25, 19 September 2022 (UTC)[reply]