Wikipedia:Village pump (technical)

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

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

   


Wikilink overlined (?!)[edit]

Usernames get overlined when hovered

Something strange is going on for me here. The mentioned usernames get overlined instead of underlined when hovered. Screenshot for example. First time ever I encounter something like this. Anyone has any idea what's going on? - Klein Muçi (talk) 14:57, 2 September 2022 (UTC)Reply[reply]

@Klein Muçi: Odd. What skin are you using? Does this still happen when you're logged out? Sam Walton (talk) 15:02, 2 September 2022 (UTC)Reply[reply]
Samwalton9, tried it in incognito (logged out) and the same behavior continued. I'm using the Vector legacy one. — Klein Muçi (talk) 15:07, 2 September 2022 (UTC)Reply[reply]
@Klein Muçi: Which browser and version? Sam Walton (talk) 15:09, 2 September 2022 (UTC)Reply[reply]
Hmm, logged out? Is this happening on every page, or only a specific page? — xaosflux Talk 15:12, 2 September 2022 (UTC)Reply[reply]
Xaosflux, @Samwalton9, Google Chrome, Ver. 105.0.5195.54 (just updated). Can't tell with certainty if it is also happening in other places as well. I vaguely remember that it was happening in some other places too before reporting but without me blindly hovering everywhere I can't say for sure. — Klein Muçi (talk) 15:18, 2 September 2022 (UTC)Reply[reply]
Is it happening on non-wikipedia pages, like search engine results? Is it happening on general wikilinks, or only usernames? — xaosflux Talk 15:19, 2 September 2022 (UTC)Reply[reply]
Can you try to start chrome with --disable-extensions and see if it changes? — xaosflux Talk 15:21, 2 September 2022 (UTC)Reply[reply]
Xaosflux, disabled all extensions, still happens. On that section there, which is all that I've tried currently, it happens only with "usernames". But strangely enough it doesn't happen on signatures. It only happens with mentioned usernames, if that makes sense. — Klein Muçi (talk) 15:29, 2 September 2022 (UTC)Reply[reply]
@Klein Muçi is this only happening when you are using that personal userscript? — xaosflux Talk 15:10, 2 September 2022 (UTC)Reply[reply]
Xaosflux, I initially reported this as a problem to the userscript's developer but it turns out it wasn't caused by it. I disabled that userscript and even tried it in safe mode but the behavior is still unchanged. — Klein Muçi (talk) 15:19, 2 September 2022 (UTC)Reply[reply]
@Xaosflux I can confirm that this is happening to me as well, as a logged out IP editor. At this mfd discussion hovering over the "G5" link causes the underline to appear over the link. Using chrome version 105.0.5195.53 on windows 10, no browser extensions in use. 163.1.15.238 (talk) 17:07, 2 September 2022 (UTC)Reply[reply]
163.1.15.238, for me as well in there. Not only for the G5 link but for the Draft:Adam Harry one too.— Klein Muçi (talk) 17:12, 2 September 2022 (UTC)Reply[reply]
Do all the other links on the page work normally? — xaosflux Talk 17:13, 2 September 2022 (UTC)Reply[reply]
@Xaosflux I've double checked, the answer is no, the second link to the deleted draft (the one with all the stuff in brackets after it) also has the underline above it. 163.1.15.238 (talk) 17:15, 2 September 2022 (UTC)Reply[reply]
@Xaosflux It appears that the upside down underline happens when a link directly follows some element that creates a list (a bullet point or a colon)? I get the same upside down behaviour looking at the pings without the leading @ character in the discussion above. 163.1.15.238 (talk) 17:19, 2 September 2022 (UTC)Reply[reply]
@Xaosflux It also seems to be related to signatures somehow. If I go to the sandbox and preview
*[[test]]
The link displays properly, if I preview
*[[test]] ~~~~
The underline appears over the text. 163.1.15.238 (talk) 17:22, 2 September 2022 (UTC)Reply[reply]
I was able to replicate this, but only in Chrome (and it was not present in Chrome v104.0.5112.102, but is in v105.0.5195.102). Seems to be related to certain elements; possibly only impacting the "first dd in a dl". — xaosflux Talk 17:40, 2 September 2022 (UTC)Reply[reply]
Is present on multiple skins here (vector-2022, vector, monobook at least) -- wonder if this is a Chrome bug. — xaosflux Talk 17:41, 2 September 2022 (UTC)Reply[reply]
It may be an improvement for accessibility purposes; Firefox has changed the default behavior of a:focus relatively recently. [1] (large page) is the full series of changes in the two versions; hover shows up over 110 times with ctrl+F. I didn't see anything in the first couple dozen. In Firefox, I don't have the issue that the above users do. Izno (talk) 17:56, 2 September 2022 (UTC)Reply[reply]
Xaosflux, Klein Muçi, 163.1.15.238, can you open the browser console and enter mw.util.addCSS('span[data-mw-comment-start]{top:unset}') ? Does that change anything?Alexis Jazz (talk or ping me) 19:01, 2 September 2022 (UTC)Reply[reply]
I can reproduce this. It is caused by invisible markers added by DiscussionTools, and it seems to be a browser bug in the latest version of Chrome (I am using Chromium 105). DiscussionTools adds markers (<span data-mw-comment-start ...>) at the beginning of each comment, placed slightly higher than the comment text, so that following a link like this will jump slightly above the comment (and highlight it). We also use these links in notifications if you're subscribed to a topic. Apparently the underline is now placed as if the whole text was in line with that invisible marker, instead of where the text really appears. Matma Rex talk 20:26, 2 September 2022 (UTC)Reply[reply]
Matma Rex, so it's not really an overline, no? It's just an underline of an invisible element. — Klein Muçi (talk) 20:35, 2 September 2022 (UTC)Reply[reply]
Yes! Matma Rex talk 20:37, 2 September 2022 (UTC)Reply[reply]
After taking a closer look, I think this is caused by the bug fix for https://bugs.chromium.org/p/chromium/issues/detail?id=1008951. The CSS spec requires that text decorations like the underline "must use a single thickness and position on each line for the decorations deriving from a single decorating box" [2] (see the picture in that link). The intent is for text like "1st" to have a single underline under the whole thing, rather than two small underlines under "1" and "st". But I think the Chrome team might have overdone it… it seems that Firefox is able to render a single underline under that text, but it doesn't have the bug you're reporting here. Matma Rex talk 20:49, 2 September 2022 (UTC)Reply[reply]
I filed a bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1359501 Matma Rex talk 21:04, 2 September 2022 (UTC)Reply[reply]

Text overline?[edit]

Screenshot showing text overline.png

Starting in the last couple of days, I've been seeing bits of text that are mysteriously overlined. I think they've all been <a> tags. If I look at the page in an incognito window (Chrome, Vector, Mac), the overline isn't there initially, but when I hover over the linked text, the overline appears. Any idea what's going on? It's the wrong phase of the week for WP:THURSDAY. -- RoySmith (talk) 17:51, 6 September 2022 (UTC)Reply[reply]

@RoySmith: It's apparently a Chromium bug. See above. Issue is being tracked upstream, and internally at phab:T317135. MusikAnimal talk 17:53, 6 September 2022 (UTC)Reply[reply]

Underlines become overlines?[edit]

Not sure what is going on here, but something changed with underlines for me recently. I use up to date Chrome on a Mac (Monterey) with the Monobook skin. When I hover over a link, usually the link becomes underlined, but sometimes the underline becomes an overline instead. This is consistent for each link. I have a CSS rule that adds underlines to interwikilinks, and they become overlines for some links. For example, the first of the two phab links in the section right above this one has an overline for me, while the second one is underlined as it should be. Does anyone have an idea what could be going on here? —Kusma (talk) 18:55, 10 September 2022 (UTC)Reply[reply]

Please see #Wikilink overlined (?!) above.  MANdARAXXAЯAbИAM  19:29, 10 September 2022 (UTC)Reply[reply]
Thanks. Not sure how I managed to miss that... —Kusma (talk) 19:35, 10 September 2022 (UTC)Reply[reply]

Article History not up-to-date when logged out[edit]

Greetings, so I just noted something weird on the article 2022 Saskatchewan stabbings: When I am logged out, it only shows me the article history up until the edit by Love of Covey on 03:20 (so this diff is the last), while the article itself shows everything as expected, including the content from e.g. my edits that happened later. I at first thought the page had some sort of WP:PCPP, but that doesn't seem to be the case. And when I'm logged in, it shows me the whole history. Is such behaviour to be expect for some reason, or is it a technical hiccup? –LordPickleII (talk) 11:47, 5 September 2022 (UTC)Reply[reply]

Same for me, but when logged out I see another revision to be the most recent one Special:Diff/(Redacted) on 4 Sept, 23:35 UTC. Although the mobile version of page history is perfectly up to date, even when logged out. CX Zoom[he/him] (let's talk • {CX}) 12:48, 5 September 2022 (UTC)Reply[reply]
I think that article should've been semi-protected by now due to vandalism and edit warring. CX Zoom[he/him] (let's talk • {CX}) 12:51, 5 September 2022 (UTC)Reply[reply]
I saw the same behaviour, but the history updated on my end when I null-edited the page. No idea what that's about. Rummskartoffel 16:08, 5 September 2022 (UTC)Reply[reply]
Someone else reported this elsewhere as well, I filed a bug as phab:T317064 with a possible cause. Legoktm (talk) 21:31, 5 September 2022 (UTC)Reply[reply]
@Legoktm: Thank you! –LordPickleII (talk) 10:19, 6 September 2022 (UTC)Reply[reply]
History links from my watchlist (right-click, Open Link in New Private Window) seem to be current. They have an additional curid parameter, for example, [3] versus [4]. Flatscan (talk) 04:46, 6 September 2022 (UTC)Reply[reply]
@Flatscan: watchlist links include a &curid= parameter to make sure the link takes you to the right page even if it's been renamed in the meantime. And the inclusion of that &curid= parameter means that caching of the history page is bypassed, so it'll always be up to date. Legoktm (talk) 14:43, 6 September 2022 (UTC)Reply[reply]
This should be fixed now. Because the fix is not retroactive, some history pages may still be stale for anons until the associated article is edited or the cached page is purged. ATDT (talk) 15:57, 9 September 2022 (UTC)Reply[reply]

Search totals capped at 10,000[edit]

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[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[reply]
And that ticket is T317374. :) Legoktm (talk) 22:42, 8 September 2022 (UTC)Reply[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[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[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[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[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[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[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[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[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[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[reply]

Elasticsearch 7 features[edit]

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[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 (talkcontribs) 08:21, 9 September 2022 (UTC)Reply[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[reply]

Weird and unhelpful autocompleted search results[edit]

As of around an hour I have had difficulty using Wikipedia because of how unhelpful autocompleted search results are now, for example typing "e" brings up "economy of the United Arab Emirates" as the first result, and I have to type out the full names of articles for them to appear now, for example writing just "uyghu" doesn't show any articles starting with the word or related to Uyghurs. Is anyone else experiencing these issues? CordiBordi (talk) 01:00, 9 September 2022 (UTC)Reply[reply]

I just wanted to add that this doesn't seem to be an isolated incident because I have been having this problem now for the past couple of hours.  Bait30  Talk 2 me pls? 01:17, 9 September 2022 (UTC)Reply[reply]
Might be related to the elasticsearch upgrade mentioned above. ScottishFinnishRadish (talk) 01:20, 9 September 2022 (UTC)Reply[reply]
Ping @RKemper (WMF) in case this is of interest to them. –Novem Linguae (talk) 01:26, 9 September 2022 (UTC)Reply[reply]
Having the same issue as well. Was searching for 8th Texas Cavalry Regiment earlier, and the fact that it didn't show up in the search bar until I had every letter typed had me almost bailing on searching because I figured there wasn't an article on it. Did the WMF break something again? Hog Farm Talk 01:54, 9 September 2022 (UTC)Reply[reply]
Just wanted to stop by and say I'm seeing the same. Autocomplete not completing article names well. 69.203.136.65 (talk) 02:03, 9 September 2022 (UTC)Reply[reply]
WP:ITSTHURSDAY :) –Novem Linguae (talk) 02:03, 9 September 2022 (UTC)Reply[reply]
I have noticed this too. NW1223<Howl at meMy hunts> 02:23, 9 September 2022 (UTC)Reply[reply]
Me too. Experienced same issue when I typed "west ed" on WP search bar on Chrome for iOS; I'm expecting West Edmonton Mall article to appear on top of search bar autofill suggestion, but other articles appear on result instead. Reminds me of a previous issue I posted here a year ago (i.e. COVID-19 and COVID-related articles not appearing on top of search bar suggestion when I typed "cov", with Coventry Cathedral and not-so-read articles showing up instead).-TagaSanPedroAko (talk) 03:51, 9 September 2022 (UTC)Reply[reply]

A bandaid fix is in place for now, which should restore search suggestions mostly. (logged out users might see issues for up to 3 hours) To give a bit of background, the search team has been working on upgrading the backend elasticsearch servers to a new major version, which has been a 3-week long endeavor (tbh it's been prepping for months, it just started being rolled out then), culminating in today's deploy that cropped up some changes/failures. Legoktm (talk) 05:26, 9 September 2022 (UTC)Reply[reply]

A draft incident report is being worked on for those interested: Incidents/2022-09-09_Elastic_Autocomplete_Missing. Legoktm (talk) 01:10, 10 September 2022 (UTC)Reply[reply]

WHOIS not working[edit]

Sorry if this has been mentioned already, but the WHOIS at Toolforge doesn't seem to have been working for several days. ♦IanMacM♦ (talk to me) 07:28, 9 September 2022 (UTC)Reply[reply]

Any link, steps to reproduce, or error message? –Novem Linguae (talk) 08:00, 9 September 2022 (UTC)Reply[reply]
If you go an IP edit in the edit history and click on WHOIS, it times out and nothing happens.--♦IanMacM♦ (talk to me) 09:12, 9 September 2022 (UTC)Reply[reply]
Courtesy links: IP contribs. Toolforge WHOIS tool.. Error message is "504 Gateway Time-out". Pinging maintainer ST47. Hasn't edited in a month though. Let me try a user talk message as well so they get an email. –Novem Linguae (talk) 09:58, 9 September 2022 (UTC)Reply[reply]
Based on the note at wikitech:Nova Resource:Tools.whois-referral/SAL, seems like this has been acting up lately - you might be able to ask someone else to restart the service in the absence of the maintainer. — xaosflux Talk 10:21, 9 September 2022 (UTC)Reply[reply]
@Ianmacm You can try the original tool in the meantime. The fork I believe is maintained by @ST47 MusikAnimal talk 16:28, 9 September 2022 (UTC)Reply[reply]

DiscussionTools at Wikipedia:Wikipedia Signpost/2022-08-31/News and notes[edit]

When trying to reply to a comment under the signpost page (where talk page is transcluded), the reply tool errors and says Could not find the comment you're replying to on the page. It might have been deleted or moved to another page. Please reload the page and try again. When going to the talk page and then clicking reply, it works. Is this a known limitation of DiscussionTools or something that should be improved? Thanks. 0xDeadbeef 16:03, 9 September 2022 (UTC)Reply[reply]

You can file a bug report on Phab if you want and tag it DiscussionTools. This might be a wontfix though since this page is wrapped in a bunch of custom HTML, which is probably what is confusing the tool, so any fix would be very specific to just the Signpost pages. –Novem Linguae (talk) 18:30, 9 September 2022 (UTC)Reply[reply]
And also that it is an entire page transclusion; on the source page (Wikipedia_talk:Wikipedia_Signpost/2022-08-31/News_and_notes) the DT's work fine. — xaosflux Talk 18:51, 9 September 2022 (UTC)Reply[reply]
This is a known issue: T259824: DiscussionTools's reply tool doesn't work when the comments are transcluded from another page using a template (not directly). I don't think we'll be able to work on this in the foreseeable future. (I'm one of the DiscussionTools developers.)
You could work around this by changing the wikitext on Signpost article pages to transclude the talk page directly, instead of using {{Wikipedia:Signpost/Template:Signpost-article-comments-end}}. You'd still have to structure it carefully to avoid running into T287040 as well. If there was interest, I could figure out how to do it and make an edit request with a proposal. Matma Rex talk 21:21, 9 September 2022 (UTC)Reply[reply]
Those templates are also used by all the archives, so you need to wrap that in a date based conditional or something or you would break those archives. There's probably also some preload template or something used to generate signpost pages that would have to be adapted. —TheDJ (talkcontribs) 08:07, 10 September 2022 (UTC)Reply[reply]

Replication seems to have stopped on enwiki_p database[edit]

Replication seems to have stopped on enwiki_p database. Is anyone aware of why that might be?

 
MariaDB [enwiki_p]> SELECT UNIX_TIMESTAMP() - UNIX_TIMESTAMP(MAX(rc_timestamp)) FROM recentchanges;
+------------------------------------------------------+

| UNIX_TIMESTAMP() - UNIX_TIMESTAMP(MAX(rc_timestamp)) |
+------------------------------------------------------+
|                                         41324.000000 |
+------------------------------------------------------+
1 row in set (0.112 sec)

William Avery (talk) 19:45, 9 September 2022 (UTC)Reply[reply]

@William Avery: possibly something to do with the ongoing maintenancehttps://replag.toolforge.org shows s1 and s4 are primarily affected, which matches those being worked on — TheresNoTime (talk • she/her) 19:53, 9 September 2022 (UTC)Reply[reply]
Thank you. William Avery (talk) 20:46, 9 September 2022 (UTC)Reply[reply]

x-tools not showing contributions[edit]

If this isn't the correct place please point me to the right 1.
I just looked at my xtools page and It's not showing today's contributions. See here: https://xtools.wmflabs.org/ec/en.wikipedia.org/Dutchy45
But as you can see here: https://en.wikipedia.org/wiki/Special:Contributions/Dutchy45 I have been active today. Anybody know the reason xtools isn't showing? Dutchy45 (talk) 20:05, 9 September 2022 (UTC)Reply[reply]

See #Replication seems to have stopped on enwiki_p database * Pppery * it has begun... 20:13, 9 September 2022 (UTC)Reply[reply]
To elaborate on the above, Toolforge/wmflabs tools such as XTools use a special copy of the SQL database called the "replica database". Usually this is an exact copy of the main database, but sometimes (such as today) these temporarily get out of sync, with the replica database lagging minutes/hours/days behind the main database. –Novem Linguae (talk) 20:25, 9 September 2022 (UTC)Reply[reply]
Thank you @Novem Linguae, @Pppery Dutchy45 (talk) 21:18, 9 September 2022 (UTC)Reply[reply]
Maybe this explains why AnomieBOT III didn't post an update on schedule at 19:37 UTC today. Maybe other bots will be affected as well. Liz Read! Talk! 21:39, 9 September 2022 (UTC)Reply[reply]
@Dutchy45: When I open xtools, there is a big banner at the top that says: Caution: Replication lag is high, changes newer than 13 hours may not be shown. At the bottom of the xtools page is a "Report an issue" button that will take you to the right place to report issue with xtool as well (as that banner is showing, I wouldn't bother opening an xtools report right now though). — xaosflux Talk 21:59, 9 September 2022 (UTC)Reply[reply]
Hello, Xaosflux,
Would this replag be affecting other operations on en-wiki besides xtools? Liz Read! Talk! 22:02, 9 September 2022 (UTC)Reply[reply]
@Liz it shouldn't impact anything on en-wiki, but it will likely affect things off-wiki. For example, Special:NewPagesfeed should be fine, but quarry would be delayed. Real-time bots like antivandalism bots would likely be fine, but a batched report creation bot that does its work off-wiki and just posts a result on-wiki may be. — xaosflux Talk 22:38, 9 September 2022 (UTC)Reply[reply]
Yes, it's the bot reports I work with either have outdated information (from this morning) or there are no updates at all. Luckily, there is always other work to be done on Wikipedia, no matter whether the bot reports are accurate or not so there is plenty to keep me busy. I just hope the replag gets caught up overnight. Liz Read! Talk! 01:20, 10 September 2022 (UTC)Reply[reply]

Vector 2022 Rollout[edit]

Folks,

I got the new Vector 2022 desktop rollout earlier today. I vaguely recollect some earlier discussions on this topic. Is there a place where I can provide feedback? Or is it too late? Unfortunately, there are quite a few issues that I see that might indicate that this is not fully ready for primetime. But, would like to connect with someone to provide my observations. Any pointers? Thanks. Ktin (talk) 23:27, 9 September 2022 (UTC)Reply[reply]

There is a huge thread at VPR, right next door. That thread has links to centralized locations for giving feedback. – Jonesey95 (talk) 23:42, 9 September 2022 (UTC)Reply[reply]

'Edit source' link opens wrong section[edit]

Surely this must have been covered before, but I can't find it either in the VP archives or in phabricator. The "edit source" link doesn't always open the right section, especially if you've come back to the page after a pause and clicked the 'edit source' link without refreshing the page. The reason for this is obvious: the link is by section number only; when you click the link, it has no idea what section 6 was when you first loaded the page, it just loads whatever section 6 is *now*. I can think of some possible fixes, but not knowing mw internals, it's hard to know what kind of effort would be involved, so I'll just say that it's broken, and leave it at that. If there's a relevant phab (or a previous VPT discussion) I couldn't find, can someone please point me to it? If there's no phab ticket, I'm happy to create one (or be my guest: your knowledge of internals and phab projects, is doubtless better than mine, and would make a better ticket). Thanks, Mathglot (talk) 03:34, 10 September 2022 (UTC)Reply[reply]

This is because names of sections are not tracked, and importantly, not unique on a page either. Well on talk pages they now actually ARE, for subscriptions etc., but on content pages they are not. @MatmaRex maybe we can fix those edit links at least on pages that DiscussionTools are active on now ? We already have the subscribe link after all. —TheDJ (talkcontribs) 11:52, 10 September 2022 (UTC)Reply[reply]
Fix ping. Matma Rex. –Novem Linguae (talk) 12:37, 10 September 2022 (UTC)Reply[reply]
DiscussionTools doesn't really help here, since its tracking of sections is not even based on wikitext markup (and it is also imperfect, in different ways: mw:Extension:DiscussionTools/How it works#Tracking topics). I would however suggest just using its [reply] links for editing on talk pages ;)
If you wanted to improve the section edit links, I think that identifying them by the heading text in addition to heading numbers would work (as proposed below and elsewhere in those tasks). It wouldn't solve the problem completely (I think it's impossible to solve while users are able to rename and move around sections in wikitext), but it would help. You'd probably also need to update the Minerva mobile skin, and the MobileFrontend and VisualEditor editors, to also support the new way, so this is a bit more work than it looks like. Matma Rex talk 18:37, 10 September 2022 (UTC)Reply[reply]
phab:T17575 is "action=edit&section=NAME not NUMBER is smarter". It was closed as duplicate of a request with different focus, phab:T11239: "edit sections by name and allow creation of sections with previously nonexistent names". My suggestion would be to allow both section name and number in the url. If there is exactly one name match then ignore the number. Otherwise use the number but possibly add a warning on the edit page. Url's with only a number should still be allowed. PrimeHunter (talk) 13:34, 10 September 2022 (UTC)Reply[reply]
That first one is exactly what I was hoping to find (it's also rather spookily similar to my description of it, right down to the example of "section 6"—which in my case stems from an actual page edit yesterday that provoked this), so thanks for linking the tickets. I see what you mean about the different focus of the newer one, which as I look at it, has tended to derail or defocus the main point of the original ticket. I'm not sure where to go next with this, but I think it should still live somewhere so that it may be acted upon, as I'm not sure the current structure will encourage that. In my book, this is in no way an enhancement request, it is a bug report, and should be labeled and treated as such. I just don't know what the best path might be to achieve that. Mathglot (talk) 04:24, 11 September 2022 (UTC)Reply[reply]

ClueBot III archive issue, anyone help?[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Hi, I recently moved my manual talk page archives to ClueBot, and it seems to have properly indexed all of my old pages - see here, which follow the format User:Andrevan/Archive54. I've set this as the archiveprefix in my template, but for some reason, when the bot actually goes to archive the page, it makes a new page called User_talk:Andrevan/Archive1. Does anyone know how to fix this issue or can tell me a good way to mass rename the old pages so I won't have this problem. Andre🚐 22:31, 10 September 2022 (UTC)Reply[reply]

@Andrevan: here's the problem: you follow the format User:Andrevan/Archive54
That should be User talk:Andrevan/Archive54. BrownHairedGirl (talk) • (contribs) 03:02, 11 September 2022 (UTC)Reply[reply]
I posted a request on AWB/Tasks asking for someone to mass move them for me. I don't know if that a thing that can be done, I don't really want to manually move 54 pages. I agree that appears like it would solve the problem. It was suggested that I troubleshoot the ClueBot template first. Andre🚐 03:54, 11 September 2022 (UTC)Reply[reply]
Got help at Wikipedia:AutoWikiBrowser/Tasks#Move my talk page archives to move to the subpage as BrownHairedGirl suggested, and if that fixes the issue, I left a note on User talk:ClueBot Commons to the effect that we should update the documentation to note that you can only have archiveprefix be a subpage of the page being archived. Andre🚐 18:37, 11 September 2022 (UTC)Reply[reply]
archiveprefix is already documented at User:ClueBot III#Required parameters. PrimeHunter (talk) 19:27, 11 September 2022 (UTC)Reply[reply]
Yes, but it does not say that you cannot set the page name to another page other than the page that is being archived. I guess it does say that but I misunderstood it. Andre🚐 19:28, 11 September 2022 (UTC)Reply[reply]
Mass rename  Done by CX Zoom, thank you! Andre🚐 19:36, 11 September 2022 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Toolserver not reachable[edit]

I am unable to get to the pageviews page - it times out, ping produces

ping pageviews.wmcloud.org

Pinging pageviews.wmcloud.org [185.15.56.49] with 32 bytes of data:
Reply from 182.79.222.166: TTL expired in transit.
Reply from 182.79.179.153: TTL expired in transit.
Reply from 182.79.222.170: TTL expired in transit.
Reply from 182.79.179.153: TTL expired in transit.

Ping statistics for 185.15.56.49:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

I have tried changing my DNS (tried 1.1.1.1, 8.8.8.8, 9.9.9.9 etc) but I can only access that page with a proxy-server. What could be the issue? Shyamal (talk) 15:06, 12 September 2022 (UTC)Reply[reply]

Hey @Shyamal, could you follow the instructions on https://wikitech-static.wikimedia.org/wiki/Reporting_a_connectivity_issue so that we can have a look? Thanks! Taavi (talk!) 15:36, 12 September 2022 (UTC)Reply[reply]
 Works for me. — xaosflux Talk 15:43, 12 September 2022 (UTC)Reply[reply]
Thanks @Taavi: - I added a report, hopefully with sufficient information/diagnostics. Shyamal (talk) 15:49, 12 September 2022 (UTC)Reply[reply]

Strange pop-up text[edit]

When I hover over a link to List of British heritage and private railways, instead of an image and a paragraph of text I see "wt2html: wikitextSize limit exceeded". Is this because there are two map templates above the first paragraph? How can it be fixed? -- Verbarson  talkedits 19:18, 12 September 2022 (UTC)Reply[reply]

If you use Navigation popups, they work fine for me. Ruslik_Zero 20:44, 12 September 2022 (UTC)Reply[reply]
No, just Page Preview. -- Verbarson  talkedits 20:49, 12 September 2022 (UTC)Reply[reply]
Yes, it seems broken. Ruslik_Zero 20:59, 12 September 2022 (UTC)Reply[reply]
The issue is with {{Map of miniature railways in the UK and Ireland}}, which has 1.6 megabytes of wikitext (!). I'm not sure how useful the map is, given that the railways aren't even visible until you zoom in a considerable distance, but the proper thing to do would probably be to move the map data to Wikimedia Commons and amend the template as described in mw:Help:Extension:Kartographer#Map data from Commons. Vahurzpu (talk) 21:37, 12 September 2022 (UTC)Reply[reply]

Help with Table[edit]

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[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[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[reply]
Thank you for the suggestion! 😃 Bgsu98 (talk) 22:52, 12 September 2022 (UTC)Reply[reply]
If that works, then that sounds like someone miscounted rowspans/colspans somewhere higher up in the table. —TheDJ (talkcontribs) 07:20, 13 September 2022 (UTC)Reply[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[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 (talkcontribs) 14:31, 13 September 2022 (UTC)Reply[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[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[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 (talkcontribs) 22:57, 13 September 2022 (UTC)Reply[reply]

Is there a way to contact IPv6?[edit]

I noticed there was a way to block ranges but I'm just wondering if there would be a way to have a way of notifying an IPv6 in the same way? I no longer have this happen but for a while I noticed my IP was changing every day here if not more than once a day, based on what happened if I was using in private browsing and looking for contributions or looking at the talk page. If you get lucky the person ends up back on the same IPv6 IP and gets the notification that there are messages on the talk page. But we can't count on that.— Vchimpanzee • talk • contributions • 22:03, 12 September 2022 (UTC)Reply[reply]

@Vchimpanzee Both IPV4 and IPV6 ranges can be blocked. There is not a way to "contact" everyone that uses a range in either case. — xaosflux Talk 22:48, 12 September 2022 (UTC)Reply[reply]
I figured if the software people could have done it, there would have been something by now. I had no idea it would be so frustrating until I was an IPv6 myself. No one seems to know why I am not any more ... oh, that's a question to ask when I pay my phone bill, and I forgot.— Vchimpanzee • talk • contributions • 22:50, 12 September 2022 (UTC)Reply[reply]
One of the potential benefits about anonymizing IPs ("IP hiding") which is a project being worked on would be to be able to contact unregistered editors who move on a range. So, that's an incidental gain. Izno (talk) 23:44, 12 September 2022 (UTC)Reply[reply]

Tech News: 2022-37[edit]

01:47, 13 September 2022 (UTC)

Section history[edit]

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[reply]

Not exactly what you're looking for, but worth mentioning: https://chrome.google.com/webstore/detail/who-wrote-that/ekkbnedhfelfaidbpaedaecjiokkionn?hl=enNovem Linguae (talk) 15:26, 13 September 2022 (UTC)Reply[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.
TigraanClick here for my talk page ("private" contact) 16:01, 13 September 2022 (UTC)Reply[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[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[reply]

Anchor years in CS1 citation module – what is it?[edit]

I’m trying to reimplement localization in the Citation/CS1/Date Validation module (on a wikipedia where the logic in check_date cannot be made to handle localized dates through the Configuration module) and trying to understand the purpose of anchor_year. Is there any documentation or examples that I can find to understand what it is exactly or what it does? Thanks in advance!—al12si (talk) 15:45, 13 September 2022 (UTC)Reply[reply]

Example:
{{cite book |last=Green |first=EB |title=Title |date=13 September 2022}}
Green, EB (13 September 2022). Title.
The rendered citation has <cite id="CITEREFGreen2022" class="citation book cs1"> where the id= attribute (the anchor id) is the concatenation of the static text CITEREF, the author's surname GREEN, and the anchor year 2022 from |date=. We can link to the example citation with wikilinks or templates:
[[#CITEREFGreen2022]]#CITEREFGreen2022
{{harvnb|Green|2022}}Green 2022
Best place to ask questions about cs1|2 is at Help talk:Citation Style 1.
Trappist the monk (talk) 16:41, 13 September 2022 (UTC)Reply[reply]
Thank you! I’m new to digging into CS1 internals (and new to Lua) and was not aware of where to find things. This is really helpful!—al12si (talk) 17:24, 13 September 2022 (UTC)Reply[reply]

DiscussionTools Beta Feature update[edit]

Almost like this, but with no arrows by the new Reply link

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

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[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[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[reply]

Hitting the emailuser rate limit[edit]

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[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[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[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[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[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[reply]
I think the solution here is fairly simple — don't do that Face-smile.svg (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[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[reply]