Jump to content

Wikipedia:Village pump (technical)/Archive 216

Add links
From Wikipedia, the free encyclopedia
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Is AutoEd safe

I installed the script and all of its modules, is it safe or not? Electrou (formerly Susbush) (talk) 19:00, 4 October 2024 (UTC)

You're responsible equally for all the edits made with automated tools, if that's what you're asking. You still have to check to make sure your edits are correct and not disruptive. Remsense ‥ 论 19:04, 4 October 2024 (UTC)
The original poster is probably referring to the message that begins "Code that you insert on this page could contain malicious content capable of compromising your account ..." at MediaWiki:Userjsdangerous. To answer the original question, yes, it is safe. Graham87 (talk) 02:05, 5 October 2024 (UTC)
You can never be sure of that about user scripts (hence the warning). AutoEd and its modules are in the Wikipedia namespace and protected, which means they can be compromised if any admin's account is compromised. Nardog (talk) 02:12, 5 October 2024 (UTC)
Yes, but the message @Graham87 linked to ends, If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump., which is what directed the OP here.
It's kind of pointless to do that if the answer is always going to be, "Weeeelll... you can never be completely certain..." — that's not helpful. The user was already warned, and while it's true that you never can be completely certain, the AutoEd code is currently safe. And since it's used by many Wikipedians, it will screw over a much larger portion of the community than just @Electrou in the unlikely event that it becomes unsafe, so it's probably not worth personally fretting over. FeRDNYC (talk) 17:35, 8 October 2024 (UTC)
Most scripts are either in the MediaWiki namespace where js pages can only be edited by interface administrators, or in userspace where they can only be edited by the user and interface administrators. AutoEd is in the Wikipedia namespace for some reason. The pages are fully protected but all administrators can edit them so it's less protected than most scripts. There are currently 847 administrators but only 10 interface administrators and it's a more trusted position. Apart from the risk of malice, ordinary administrators may also know less about JavaScript and security (including securing their account), and accidentally do something unsafe. PrimeHunter (talk) 20:46, 8 October 2024 (UTC)

Table

How to make this table look like this one? I don't see any parameters which could be used. Eurohunter (talk) 20:52, 7 October 2024 (UTC)

What do you mean "look like"? They look roughly the same to me, except for some styling applied by |namestyle=, |headingstyle=, |class=, and similar. – Jonesey95 (talk) 21:24, 7 October 2024 (UTC)
I'm gonna dissent from @Jonesey95's claim as those boxes look pretty significantly different to me, but I agree it's mostly a question of styling, all of which is done by parameters that most assuredly are there and being used ­— most of what's involved in making Template:Politics of Yemen look more like Template:Politics of Uzbekistan would involve removing the ugly style nightmare that's been imposed on the former. Places I'd start:
  • Lose the border: 1px double #8C959A from all of the style parameters where it's used (titlestyle, headingstyle, and listtitlestyle), because that just looks like trash.
  • Just remove |style=border 4px double var(--background-color-inverted, #101418); completely. (What is this obsession with double-lined borders?)
  • Use {{Politics sidebar title}} to set the |title= parameter, rather than hardcoding separate |title=, |image=, |namestyle=, |titlestyle=, etc. Specifically, you'd probably want this:
    |title={{Politics sidebar title|country=Yemen|image=Emblem of Yemen (2).svg|size=125px|title=Yemen}}
    replacing not only |title= itself but also those other three parameters.
  • Consider getting rid of the |headingstyle= and |listtitlestyle= entirely, as well. Beyond the border styling, all they do is set specific (and ugly) color parameters that ruin the look of the sidebar because content boxes of unequal dimensions are revealed. That makes for a very "ransom-note" kind of effect where different-sized yellow rectangles and red rectangles are slapped all over the place.
  • Finally, if you don't want the contents of each expandable heading to be presented as just a wrapped horizontal line of text, remove hlist from the |bodyclass= parameter, as that's what makes them format that way.
    (If you do that, you might consider using the {{hlist}} template to create horizontal lists out of some of the links in specific lists, like Template:Politics of Uzbekistan does in the |list6= contents.)
FeRDNYC (talk) 22:34, 8 October 2024 (UTC)

Lua to generate information about a page

Hello, does lua template have the capability to get information like

  • page contributors
  • last date of edit to page

for a provided page name? If so, please send me an example? Thank you. Gryllida (talk, e-mail) 07:23, 7 October 2024 (UTC)

@Gryllida: You don't need Lua for the second one, it is available as a variable. If you only need the last contributor, that also is available in the same way. --Redrose64 🌹 (talk) 09:40, 7 October 2024 (UTC)
Need this info for page and for page talk so I think variable will not work. Need a list of contributors not only last one. I can get this information using js but would prefer to avoid it. if possible. Thanks. Gryllida (talk, e-mail) 14:16, 7 October 2024 (UTC)
Why do you think that a variable wouldn't work? Consider the article London - we can do this:
  • {{REVISIONTIMESTAMP:London}} → 20241021231522
    {{#time: H:i, j F Y (e)|{{REVISIONTIMESTAMP:London}}}} → 23:15, 21 October 2024 (UTC)
  • {{REVISIONTIMESTAMP:Talk:London}} → 20240908185015
    {{#time: H:i, j F Y (e)|{{REVISIONTIMESTAMP:Talk:London}}}} → 18:50, 8 September 2024 (UTC)
If either London or Talk:London get edited, the above examples will change when this page is next edited or WP:PURGEd. --Redrose64 🌹 (talk) 16:04, 7 October 2024 (UTC)
This is fabulous Thanks. I will go try to use it in my template now. Just need the nicks of contributors now if possible. Gryllida (talk, e-mail) 22:59, 7 October 2024 (UTC)
No, Lua (Scribunto) does not have access to page history. One option would be to have a bot periodically build a list of contributors and update a page somewhere that a module could read. Or, have a JavaScript gadget which can use the API. All that is tricky. Johnuniq (talk) 00:41, 8 October 2024 (UTC)
Js is ok,I can write. I was hoping for Lua. Why not? Can it be implemented for Lua to have such access? Thanks for your insight. 🙂 Gryllida (talk, e-mail) 10:28, 8 October 2024 (UTC)
Part of the answer to that question is likely something vaguely along the lines of, "just as we expect of all wikipedians, Scribunto is here to create an encyclopedia, and no part of that goal ever requires access to edit history."
(Which... is actually kind of true. There are plenty of behind-the-scenes tasks/goals that could benefit from page history access, but none of them would ever directly affect article content.) While there are plenty of conceivable ways in which it would be useful to have history access (or other functionality) in Scribunto, the focus has primarily been on providing functional equivalents to what's achievable with template coding, but without the template-coding nightmares involved in building any sort of complex logic.
Templates similarly have no access to page history.
Another factor is that the results of Module {{#invoke:}} calls, like template transclusions, are meant to be cacheable. 'Dynamic' code that relies on making an external resource query, meaning it potentially changes each time the module is invoked, is a bad fit with the caching model. Lua results should ideally be fairly static unless a dependency is edited or the code is invoked with different parameters.
Not to say that these things couldn't, potentially, be implemented. They just haven't been, and adding them would be a significant development effort, it's not a matter of flipping a switch or inserting a line of code somewhere. In fact there's a Phabricator tracking bug (T50176) for bugs requesting new Lua functionality — it's a long list. Things like MediaWiki API query access, access to Category lists, Namespace indexes, etc. are already there. It doesn't look like edit history access has ever been directly requested. (But API queries would provide one potential path, since page history info is accessible via the API.)
It's important to note that none of those requests are actively being worked on, though. They're just that: Requests. Unfulfilled requests, with no predicted timeline for completion beyond "...probably never?" FeRDNYC (talk) 21:52, 8 October 2024 (UTC)
i wanted list of article authors to inquire about edit to the article, e.g. send @ pings on talk. Gryllida (talk, e-mail) 03:35, 9 October 2024 (UTC)
Your best bet will be to use xtools to generate a list of people who edited the article by using this link: [1] NightWolf1223 <Howl at me•My hunts> 03:41, 9 October 2024 (UTC)
Tracked in Phabricator
Task T376848

The message "This is an old revision of this page" or "This is the current revision of this page" at the top of a permalink has the cdx-message--warning class but is not styled unless the skin is Vector 2022 (example). Is there a Phab task for this? Nardog (talk) 06:26, 9 October 2024 (UTC)

There were several tasks about missing warning box styling in various places, but I don't think there was a task about this particular one. Please file it. :) Matma Rex talk 16:15, 9 October 2024 (UTC)
@Matma Rex: Done. Please add appropriate tags; I didn't file it earlier mainly because I didn't know what tags to use. Nardog (talk) 23:06, 9 October 2024 (UTC)

Alternative to normal talkpage notification

Something I've been thinking about:

A lot of new people don't seem to see talkpage messages. The cause is not really important here; it may be a case of banner blindness, or our (mobile) interface is not clear enough, or whatever.

Would it be a good idea to implement a special message notification, perhaps one that:

  • is hard to ignore
  • can perhaps only be sent by an admin
  • requires confirmation of receipt to dismiss (so it is on every page you visit until you click a button)
  • takes up most if not all of the screen
  • would still appear on the talkpage as a normal message so others can see them as well
  • comes with a short explanation that someone is trying to reach them, translated in many languages

To prevent abuse in case of hijacked admin accounts we could restrict each message to only one recipient, and limit the amount you can send to 1 per minute. And perhaps it should only be possible to send such messages to people who are not extendedconfirmed. To prevent people receiving too many of these messages, perhaps limit them to, for example, 1 per hour per recipient.

Ideally those You may be blocked from editing without further warning the next time you... warnings would be sent via this alternative method of talkpage notification.

A potential downside is that its, in some cases, easier to give someone WP:ROPE and then not have to deal with them for the duration of their block.

I think that at least some people keep doing what they are doing, without ever noticing a growing list of messages on their talkpage of people trying to steer them in the right direction. Has such a feature been considered?

Polygnotus (talk) 02:51, 10 October 2024 (UTC)

Works in Special:ExpandTemplates but fails in regular page?

As I am climbing the bumpy learning curve for templates I hit another road block. This code (with extra double curlies on the outside) evaluates when I use Special:ExpandTemplates but just sits there in a page like this:

  • {{
  • common:−4, +4,
  • notable:−3,[1] −2,[1] −1,[1] 0, +1,[1] +2,[1] +3,[1]
  • predicted:
    }}

My goal was to have a database layer accept the name of a formatter and a selector, then return a template with that formatter and the selected data. It works in ExpandTemplates, but where it counts. Any hints? ([2])

Johnjbarton (talk) 21:43, 9 October 2024 (UTC)

Oh, I unchecked Remove comments on the ExpandTemplates and the result is different. Still in the dark though. Johnjbarton (talk) 21:51, 9 October 2024 (UTC)
This is a known, and annoying, but in ExpandTemplates, which half-parses the text and then parses it fully. How the ordinary parser works is that if a template outputs wikitext that wikitext doesn't get parsed again. If you really want to run through the parser multiple times you can use {{expand wikitext}}, so {{expand wikitext|{{ {{User:Johnjbarton/sandbox/Infobox element/symbol-to-oxidation-state-data|os-formatter=User:Johnjbarton/sandbox/Infobox element/symbol-to-oxidation-state-echo|symbol=C}} }} -> (example removed since template changes made it obsolete). While I've done that in the past it's kind of hacky.
You also need to put a space between the two sets of curly brackets, or else the parser gets confused. {{{{1}}}} is parsed as { {{{1}}} } (take the value of a parameter and wrap it in curly brackets), not {{ {{1}} }} (evaluate Template:1 and then evaluate the result of it as the name of another template). * Pppery * it has begun... 22:22, 9 October 2024 (UTC)
Also if you were to put the opening curly braces in User:Johnjbarton/sandbox/Infobox element/symbol-to-oxidation-state-data itself, then that would work. (this is similar to how {{country data United States}}) et al. work. * Pppery * it has begun... 22:36, 9 October 2024 (UTC)
Ok great thanks! These are the kinds of things I need to learn:
  • "How the ordinary parser works is that if a template outputs wikitext that wikitext doesn't get parsed again."
I was able to base my prototype on {{country data United States}} by changing the design of the "data". This kind of system is much easier to use with good examples. Johnjbarton (talk) 02:39, 10 October 2024 (UTC)
You're welcome. Also, I misspoke - a better way of phrasing it is "How the ordinary parser works is that if a template outputs template calls those template calls don't get parsed again" - other wikitext like wikilinks, refs, etc. is of course parsed. There's a very long manual on how the parser works at mw:Help:Template and even more stuff at mw:Manual:Advanced templates if you want to really enter the weeds. * Pppery * it has begun... 04:51, 10 October 2024 (UTC)

References

  1. ^ a b c d e f Greenwood, Norman N.; Earnshaw, Alan (1997). Chemistry of the Elements (2nd ed.). Butterworth-Heinemann. p. 28. ISBN 978-0-08-037941-8.
  2. ^ ignore ref

youtu.be blacklist

When I share a youtube video with a timestamp I get a link like this:

https://youtu.be/Zl8BIUx8QW0?feature=shared&t=1

but when I try to post that on wikipedia it says the link is on a spam blacklist. I can't find it on meta:Spam blacklist or on MediaWiki:Spam-blacklist.

And it wouldn't even make sense to block it anyway because I can change the link to:

https://www.youtube.com/watch?v=Zl8BIUx8QW0#t=1

and suddenly it is allowed. Polygnotus (talk) 21:24, 6 October 2024 (UTC)

Shorteners are categorically rejected. This one is rejected at meta:Spam blacklist \byoutu\.be\b. Izno (talk) 21:29, 6 October 2024 (UTC)
Thank you. The spam blacklist is intended to blacklist spam, and shouldn't be hijacked by people with an irrational hatred for url shorteners. Polygnotus (talk) 21:36, 6 October 2024 (UTC)
URL shorteners are used to introduce spam, and aren't always particularly stable addresses, and they can lead to hijacked sites, which are much more dangerous than spam. These reasons for banning them are categorically rational, contrary to your hyperbole. No, they will remain banned. Whether specifically youtu.be should have an exception is perhaps a worthy question, but as you said, the expansion is trivial, so just use the full URL instead. Izno (talk) 21:48, 6 October 2024 (UTC)
Yes. Shirley there Izno reason not to use the full URL. EEng 23:07, 7 October 2024 (UTC)
@Izno: I know what URL shorteners are. This particular URL shortener cannot be used for malicious purposes because it only redirects to youtube. So it is obviously irrational to block all url shorteners. It is rational to block attack vectors while leaving domain aliases unblocked. This kinda stuff should be decided on a case-by-case basis (e.g. block bit.ly and tinyurl but not youtu.be). I can use the full url, but others do not know how to do that. Polygnotus (talk) 22:00, 6 October 2024 (UTC)
If someone doesn't know what a URL is or how to copy and paste it, they definitely shouldn't be adding external links to articles. Thebiguglyalien (talk) 06:27, 7 October 2024 (UTC)
@Thebiguglyalien: If someone says something truly ridiculous, it is often wise to re-read it in its context. Polygnotus (talk) 06:30, 7 October 2024 (UTC)
URL shorterners are blacklisted for good reasons. They can be used to circumvent blacklisting of their target. MediaWiki:Spam-blacklist blacklists several specific videos at youtube.com, e.g. the entry \byoutube\.com\/watch\?v=W0a6L7hbD7U\b. We don't want spammers to use a youtu.be redirect instead. And there are other problems with URL shorternes, e.g. that they can be shut down and break all links. If you don't think YouTube's owner Google would do such a thing then think again. They are shutting down their URL Shortener goo.gl.[2] PrimeHunter (talk) 21:55, 6 October 2024 (UTC)
Gotta love https://killedbygoogle.com/ Polygnotus (talk) 22:00, 6 October 2024 (UTC)
I actually agree that youtu.be shouldn't be blacklisted. The solution to PrimeHunter's concern would be to just blacklist the string W0a6L7hbD7U instead - the blacklist doesn't have to point to the full URL. But despite being a Meta admin and thus having the technical power to action this I don't have the social power to do it myself. * Pppery * it has begun... 02:26, 7 October 2024 (UTC)
@Pppery: Thanks! The discussion continues at meta:Talk:Spam_blacklist#youtu.be. Another advantage of blocking W0a6L7hbD7U is that it would work for both the youtu.be/%id% and /watch?v=%id% format. Polygnotus (talk) 02:33, 7 October 2024 (UTC)
The key point here, which was (indirectly) mentioned by the OP, is that https://youtu.be/video_id links are provided by YouTube itself directly from their UI whenever a "Share" link is requested for a video. They are, in a certain sense, even more of a permalink than the actual https://www.youtube.com/watch?v=video_id page they redirect to.
And while it's true Google could terminate support for https://youtu.be/ tomorrow, they could also redesign YouTube tomorrow so that the https://www.youtube.com/watch page is no longer functional, replaced by https://www.youtube.com/view or some other nonsense, which the https://youtu.be/ redirects get updated to point to.
Do I think that will happen? Absolutely not; I just think it's of equal unlikelihood (...ow) that anything will happen to https://youtu.be/, as that would break like a quarter of the entire frickin' internet.
The simple fact is, when requesting links to YouTube videos from YouTube itself, users are provided with https://youtu.be/ links, which IMHO we shouldn't make it unreasonably difficult to make use of.
Especially considering, if a user is viewing a video in the YouTube mobile app (which accounts for a very significant percentage of YouTube traffic, at a level that shames our own mobile app's laughable 2%-3% of monthly pageviews), the short URL is the only URL they can retrieve. The app doesn't expose https://www.youtube.com/watch?v=video_id URLs anywhere. FeRDNYC (talk) 18:03, 8 October 2024 (UTC)
Linking to invidious instance could be better, it loads faster and does not track the user as much. Gryllida (talk, e-mail) 07:26, 7 October 2024 (UTC)
See Principle of least astonishment. Polygnotus (talk) 07:28, 7 October 2024 (UTC)
The two issues appear to be the general issue with url shorteners, and spamming of the shortened url.
Although this is a url shortener it's doesn't have the issues inherent in most shorteners. The only end point is a youtube video, so the usual concerns that it could link to anything do not apply here. Whether you use .com or .be you can't link to anything but a youtube video (correct me if that's wrong).
The spam issue is separate, and blacklisting individual videos is a poor option unless it's in a very particular situation. But the .com version could be spammed as well. I don't know how long ago the spamming and blacklisting were, but maybe unblacklisting as a test would be useful. If the past issues reappear it could be reapplied. I can see reasons why the .be link would be easier to spam, but beans. -- LCU ActivelyDisinterested «@» °∆t° 18:59, 8 October 2024 (UTC)
While it doesn't directly - it does procedurally. In many use cases using the youtube "share button" generates a shortener that also includes a tracker, which we don't want. And 'someone else can go back and remove trackers later' isn't a strong argument - bad edits that can easily be avoided (by just using the actual link) are much more desirable. — xaosflux Talk 10:29, 10 October 2024 (UTC)
@Xaosflux: In GDPR countries that tracking parameter is omitted. Polygnotus (talk) 10:37, 10 October 2024 (UTC)
Sometimes sure, and in the rest of the world it's not. — xaosflux Talk 10:49, 10 October 2024 (UTC)
I would propose to develop a mechanism to expand the shortened URL to its full form. For example, either
  • write a bot that automatically expands certain short URL patterns upon user publishing an edit, and if the expanded URL hits the spam blacklist, revert the edit. There are already external Spam blacklist search tools [3]. Or,
  • integrate the short URL expansion mechanism into MediaWiki, automatically expand shortened URLs upon publishing. If the expanded URL hits blacklist then disallow the edit.
MilkyDefer 08:23, 10 October 2024 (UTC)
Oh great, it is in idea lab. MilkyDefer 08:29, 10 October 2024 (UTC)
Link for those curious: Wikipedia:Village_pump_(idea_lab)#URL_expansion_bots Polygnotus (talk) 08:31, 10 October 2024 (UTC)

Hot cat not working and visual editor not as easy

I was setting up the article at Gábor_Bálint and wanted to add the "category:Hungarian linguists" and it did not work because that category does not exist. I finally found "category:Linguists from Hungary" and I usually do not like this inconsistency (and especially do not see why American and English are special nationalities) so I added {{Category redirect|Linguists from Hungary}} at the wrong category. Now hot cat usually uses that and helpfully replaces the category if I typed "Hungarian linguists". Strangely hot cat does not seem to work at all today and the visual editor for categories does not have this automatic feature to suggest preferred category names. Perhaps someone knows a better way of explaining this or adding a suggestion for the visual editor folks. PS:hot cat now working!! Shyamal (talk) 12:48, 10 October 2024 (UTC)

Adding section after closed discussions

I added a new section using the "*" tab with this edit: https://wiki.riteme.site/w/index.php?title=Talk:Fishing_cat&curid=7607570&diff=1250477244&oldid=1250369650

The new section is included within the closed discussion. I might be able to fix it in this case, but it seems to be a bug.  —  Jts1882 | talk  19:03, 10 October 2024 (UTC)

It's not really a bug; the person who closed the GA review section forgot to match their {{atop}} template with an {{abot}} template, which means the "close" box didn't end. I've fixed it. Writ Keeper ⚇♔ 19:10, 10 October 2024 (UTC)
Thank-you. I knew there was a problem but couldn't identify it. It's too easy to cast blame on bugs.  —  Jts1882 | talk  19:18, 10 October 2024 (UTC)

Matching tags in strings?

I need to create a series of ref tags from wikitext with refs. I'll settle for a very specific pattern of text removed. I tried things like: {{#invoke:string|replace|source=−4,<ref name="cn"/> −2,<ref name="cn"/>|pattern=[−+]%d,<.-><|replace=<|plain=false}} but the left angle bracket never matches. I think the match is being performed on a source or pattern after it has been converted to Help:strip markers. Thus the angle bracket is not in the source during the match. Is there a way around this? Johnjbarton (talk) 23:15, 10 October 2024 (UTC)

Because <ref /> tags are replaced with stripmarkers before Module:String ever sees |source=:
{{#invoke:string|replace|source=−4,<ref name="cn"/> −2,<ref name="cn"/>|pattern=[−+]%d,<.-><|replace=<|plain=false}}
−4,'"`UNIQ--ref-0000002D-QINU`"' −2,'"`UNIQ--ref-0000002E-QINU`"'
no <ref /> tags to match.
—Trappist the monk (talk) 00:40, 11 October 2024 (UTC)
Thanks, very helpful. On the plus side the issue I was concerned about, finding my digit-strings like ",9" inside refs, can't actually happen:
{{#invoke:string|replace|source=−4,<ref name="has9">,9</ref> −2,<ref name="cn"/>|pattern=[−+]%d,<.-><|replace=<|plain=false}}
−4,'"`UNIQ--ref-00000031-QINU`"' −2,'"`UNIQ--ref-00000032-QINU`"'
On the minus side, templates can't manipulate contents of ref tags I guess. Johnjbarton (talk) 01:55, 11 October 2024 (UTC)

References

  1. ^ a b c d Cite error: The named reference cn was invoked but never defined (see the help page).

Help Escalating security issue with Webauthn

Tracked in Phabricator
Task T358771

With the help of WMF staff we identified a critical issue with webauthn that is likely locking users out of their accounts. The issue prevents webauthn activated on a device from being used on another device, or between browser sessions. This means users can be activating webauthn , intending to secure their account, and end up losing access to wikipedia. Because relatively few users activate this feature in the short term, the issue may not be getting the attention it deserves. It will also discourage future users from activating webauthn, which is a critical security feature to protect the community.

Please help me find the appropriate contact with WMF technical staff to help get the fix merged. It's a one-line fix from upstream repository so it should be low risk. Tonymetz 💬 16:50, 3 October 2024 (UTC)

I guess that would be us, the Platform Team. I'll raise it with the team and we'll have a look. Matma Rex talk 19:30, 3 October 2024 (UTC)
Thanks for the note, webauthn has multiple known issues and is certainly in the "experimental" role. As far as our contributors and readers here at the English Wikipedia go: webauthn shouldn't be used by anyone for anything important. Technical reports in phabricator are of course welcome. — xaosflux Talk 00:09, 5 October 2024 (UTC)
thanks for the context. On the ticket , Reddy mentioned it was completed by a contractor and hasn't been supported. To whom could I appeal to have it turned off? I believe it's locking people out, so it's a liability. Tonymetz 💬 18:00, 7 October 2024 (UTC)
I think that would also be us. There's already a task: T376021 that lists some problems and suggests turning it off as one possible solution. I think that's currently waiting on some decisions about the new login system (code name "SUL3", see T348388 for some details), which may either let us fix it instead of disabling it, or force us to disable it, depending on which approach we end up going with. Matma Rex talk 01:10, 10 October 2024 (UTC)
thanks for sharing the context and I'm glad to hear that the concern is being addressed. Thanks again for the updates on that. Tonymetz 💬 02:58, 11 October 2024 (UTC)

Sticky table headers placement issue for short/nested tables

It looks like someone tweaked the CSS for the sticky table headers — which can be enabled with the fourth checkbox at Special:Preferences#mw-htmlform-gadget-section-test — so that (if your browser also satisfies a @media screen and (min-width: 1000px) media query) it applies a top: 3.125rem offset to table headers when one is stickied, to prevent the sticky header from either covering or sliding under the also-sticky TOC button.

Nice idea, in theory. Problem is, on pages containing nested and/or short tables that don't exceed the height of the screen, the stickiness can kick in at unexpected times, particularly when there are multiple tables. And when that happens, all of the tables' headers jump down a distance of 3.125rem, potentially covering their first data row.

I first noticed this at Module:Sports results, in the documentation. The "What it looks like" areas of those docs all contain short tables. If you have the sticky headers gadget enabled, then no matter where you scroll on that page, each table's header row will be shoved down to cover the first data row below it.

That's a problem, as it obscures content, and the only way to make it visible is to defeat the CSS rule applying top: 3.125rem. FeRDNYC (talk) 16:16, 8 October 2024 (UTC)

Actually, it looks like this only affects nested tables, and it may be sufficient to augment the existing CSS rule: 
@media screen and (min-width: 1000px) {
  .skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter > thead,
  .skin-vector-2022.vector-sticky-header-visible .mw-sticky-header > thead {
    top: 3.125rem;
  }
}
with a second one overriding the offset in nested tables:
@media screen and (min-width: 1000px) {
  .skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter .jquery-tablesorter > thead,
  .skin-vector-2022.vector-sticky-header-visible .jquery-tablesorter .mw-sticky-header > thead,
  .skin-vector-2022.vector-sticky-header-visible .mw-sticky-header .mw-sticky-header > thead,
  .skin-vector-2022.vector-sticky-header-visible .mw-sticky-header .jquery-tablesorter > thead {
    top: 0;
  }
}
FeRDNYC (talk) 16:57, 8 October 2024 (UTC)
...Smaller issue, the nested table headings then end up passing on top of the sticky outer table headers when they cross, instead of underneath them. Looks like some z-index tweaking might also be needed. FeRDNYC (talk) 17:01, 8 October 2024 (UTC)
Ohh, now I see. The offset isn't to avoid the floating TOC button, but rather the full-width version of the .vector-sticky-header. But the weird thing is, that CSS doesn't kick in until @media screen and (min-width: 1120px), so there's this weird 120px limbo range of browser widths where the table headings are ducking under nothing at all. FeRDNYC (talk) 22:53, 8 October 2024 (UTC)
Those values change sometimes. I'll make an edit request. —TheDJ (talk • contribs) 08:16, 9 October 2024 (UTC)
@TheDJ Nice, thanks!
The nested table issue is still a problem, though, whether the breakpoints are synced up or not. When a table's sticky-header activates and the top: 3.125rem; offset kicks in for its header rows, the header rows of all tables nested inside that table will also move down to obscure their own content, unless the offset is defeated for nested tables with something like my second CSS block above. FeRDNYC (talk) 09:18, 9 October 2024 (UTC)
Yes, this is almost impossible to bypass. Sticky headers are relative to their scrolling context. So every time you introduce a new scrolling context (as done here at Module:Sports_results#L-277), you have to cancel out the offset of the main context. This is part of the reason why the sticky headers are not the default behavior. It is not really possible to make it work predictably in any and all contexts right now. If you want to override this specific situation, you need to make an override for this gadget's behavior in Module:Sports_results/styles.css. —TheDJ (talk • contribs) 11:11, 9 October 2024 (UTC)
@FeRDNYC: The offset isn't a problem with the change request at MediaWiki talk:Gadget-StickyTableHeaders.css#Interface-protected edit request on 10 September 2024, which adjusts "top" to 0 if the table is wrapped in an "overflow" style. Basically nothing is sticky at Module:Sports results/doc, which is better than unreadable content. Jroberson108 (talk) 05:55, 11 October 2024 (UTC)

Talk:Battle of Helena

See Talk:Battle of Helena#In appropriate photo when viewing in app. Any idea what's going on with the issue the IP just reported? There were some image vandalism issues over a year ago. There's no infobox image in the article so I don't know what would be causing that. I am unable to really look into this because I am at work and do not want to replicate the reported issue. Hog Farm Talk 16:29, 11 October 2024 (UTC)

@Hog Farm the article was vandalized at some point (see the edit summary at Special:Permalink/1163371835) and while the vandalism was removed, it's likely that some resource the app is using didn't update their cache correctly. --Ahecht (TALK
PAGE) 19:53, 11 October 2024 (UTC)

SuggestBot - is it running?

Hi, I submitted a request 20:32, 10 October 2024 (UTC) here, and awaiting a response of suggested articles wikitable. At User talk:SuggestBot I did include @Nettrom, the bot operator. Regards, JoeNMLC (talk) 21:41, 11 October 2024 (UTC)

It appears not - the recent contribs to User talk pages show that it typically runs twice a day, at 11:24 and 23:24 (UTC), but today's 11:24 run was missed. Have you contacted the botop directly? --Redrose64 🌹 (talk) 21:55, 11 October 2024 (UTC)
Thanks Redrose64 - I did just now leave a message on Nettrom's talk page. JoeNMLC (talk) 00:10, 12 October 2024 (UTC)
Well its contribs show that it's making edits (permalink to contributions at time of writing). It seems to be taking its time. At least it's still carrying on the fourth-longest daily editing streak of any user here (I'm at #5 of out of all human editors). Graham87 (talk) 02:44, 12 October 2024 (UTC)
 Done at 11:26, 12 October 2024 (UTC). Cheers! JoeNMLC (talk) 11:50, 12 October 2024 (UTC)

Queries

Hey, all,

Just a minor query but I hope someone will know. When I use to visit Wikipedia:Arbitration/Requests/Enforcement or WP:ANI, in the top right corner of a discussion, there was a link to "Archive" the discussion. Instead, now, there is a link to "Subscribe". So, is there an easy way to archive discussions other than cutting and pasting them into an archive page? It used to be easy to do this but now I don't see a way to do this. Is it because of a skin or some setting I have opted into or was this a change to discussion format? There also use to be a Reply link on talk page discussions and I no longer see that link either.

Thanks for any explanation anyone can provide. Liz Read! Talk! 06:06, 12 October 2024 (UTC)

I had this issue recently and I was told to update / use a new user script. Let me hunt that down for you. Ktin (talk) 06:25, 12 October 2024 (UTC)
See this post Wikipedia:Village_pump_(technical)/Archive_214#User_Scripts_and_Template_Substitution. I ended up using User:Elli/OneClickArchiver and this works for me. Ktin (talk) 06:29, 12 October 2024 (UTC)
@Liz In User:Liz/common.js you are loading User:Technical 13/Scripts/OneClickArchiver.js on line 36. That particular version of the one click archiver was deleted in 2023 because it was broken and Technical 13 is arbcom blocked and unable to fix it. You'll need to replace it with an alternative, see Wikipedia:One click archiving for a list of maintained versions. 86.23.109.101 (talk) 17:11, 12 October 2024 (UTC)

‘Newcomer Tasks’ got a screw loose? Or is it the user?

Wikipedia:Growth Team features didn’t look like the right place to phone this in, so dragging it up here. If what looks like problems with the Newcomer kit, belongs somewhere else, please signpost accordingly.

See this and this. Is this the user making mistakes, or is Newcomer Tasks actually telling them to put refs at the top? MM (Give me info.) (Victories) 15:44, 13 October 2024 (UTC)

It seems to be just link spam, unrelated to Newcomer Tasks, even though the edits are tagged as such. —⁠andrybak (talk) 15:53, 13 October 2024 (UTC)
Cpmrev- Jeez, how did I miss that… uw-spam1 it is. Cheers Andry. MM (Give me info.) (Victories) 15:57, 13 October 2024 (UTC)

Standard width of appearance tool does not work properly

Hi, "Standard" width of "Appearance tool" does not work properly. It functions the same as "Wide" width. Please inspect. Thanks, Hooman Mallahzadeh (talk) 12:52, 14 October 2024 (UTC)

I just tested and it works fine. Is your screen wide enough for the wide mode to even kick in ? —TheDJ (talk • contribs) 14:00, 14 October 2024 (UTC)
@TheDJ Sorry, I zoomed out my browser and the problem resolved. Please close the thread. Thanks. Hooman Mallahzadeh (talk) 14:13, 14 October 2024 (UTC)
@TheDJ I really propose that we can disable this functionality in the case that zoom of browser is high, and this functionality does not work properly. We can implement that by a few JavaScript codes. Hooman Mallahzadeh (talk) 14:33, 14 October 2024 (UTC)

Cannot request a move

I have been unable to request a multiple-page move. It goes like this: I am using Wikipedia on an Xbox console (my computer is out of action at the moment), and attempting to request a multiple-page move does not work. Doing so instead yields a mere reply in the form of bare wikitext. You can find those three trainwrecks (or should it be planewrecks, given the topic?) on Talk:Microsoft Flight Simulator. I attempted to request a move of four pages relating to the series in question, as I had previously done with the first game: Microsoft Flight Simulator 2.0, Microsoft Flight Simulator 3.0, Microsoft Flight Simulator 4.0, and Microsoft Flight Simulator 5.0 in a similar vein to my move of the 1982 game, as in moving them to something like "Microsoft Flight Simulator (19XX video game)".


Can someone request a move for me? Ægc's friendly xbox alt (talk) 08:30, 14 October 2024 (UTC)

Turn off Visual Editor in all its myriad forms (it may be OK for articles, but it's hopeless on talk pages). Use MediaWiki's own plain text source editor - I use the oldest one that still exists (I think that it's called the 2003 wikitext editor), and have no problems at all. Template transclusions and substitutions do exactly what they're supposed to. Any typos are therefore my own fault. --Redrose64 🌹 (talk) 09:41, 14 October 2024 (UTC)
@Redrose64 I don't think this is good advice in general, and it's not relevant here, because Æ is not using the visual editor here to edit the talk page, but rather the new topic tool. Matma Rex talk 16:00, 14 October 2024 (UTC)
@Ægc's friendly xbox alt In the top-right corner of the interface for adding new topics, there are two tabs labelled "Visual" and "Source" – try switching to the "Source" tab before writing the move request. Matma Rex talk 15:58, 14 October 2024 (UTC)

Tech News: 2024-42

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Updates for editors

  • The Structured Discussion extension (also known as Flow) is starting to be removed. This extension is unmaintained and causes issues. It will be replaced by DiscussionTools, which is used on any regular talk page. A first set of wikis are being contacted. These wikis are invited to stop using Flow, and to move all Flow boards to sub-pages, as archives. At these wikis, a script will move all Flow pages that aren't a sub-page to a sub-page automatically, starting on 22 October 2024. On 28 October 2024, all Flow boards at these wikis will be set in read-only mode. [4][5]
  • WMF's Search Platform team is working on making it easier for readers to perform text searches in their language. A change last week on over 30 languages makes it easier to find words with accents and other diacritics. This applies to both full-text search and to types of advanced search such as the hastemplate and incategory keywords. More technical details (including a few other minor search upgrades) are available. [6]
  • View all 20 community-submitted tasks that were resolved last week. For example, EditCheck was installed at Russian Wikipedia, and fixes were made for some missing user interface styles.

Updates for technical contributors

  • Editors who use the Toolforge tool Earwig's Copyright Violation Detector will now be required to log in with their Wikimedia account before running checks using the "search engine" option. This change is needed to help prevent external bots from misusing the system. Thanks to Chlod for these improvements. [7]
  • Phabricator users can create tickets and add comments on existing tickets via Email again. Sending email to Phabricator has been fixed. [8]
  • Advanced item Some HTML elements in the interface are now wrapped with a <bdi> element, to make our HTML output more aligned with Web standards. More changes like this will be coming in future weeks. This change might break some tools that rely on the previous HTML structure of the interface. Note that relying on the HTML structure of the interface is not recommended and might break at any time. [9]

In depth

  • The latest monthly MediaWiki Product Insights newsletter is available. This edition includes: updates on Wikimedia's authentication system, research to simplify feature development in the MediaWiki platform, updates on Parser Unification and MathML rollout, and more.
  • The latest quarterly Technical Community Newsletter is now available. This edition include: research about improving topic suggestions related to countries, improvements to PHPUnit tests, and more.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 21:17, 14 October 2024 (UTC)

Preview weirdness

Use Navigation pop-ups. Point mouse at Aaron Brennan, an article about a bearded man, with a picture of a bearded man in the infobox, before any other pictures. Be surprised to see, in the pop-up, a picture of an unbearded young lady from several sections down the page. DuncanHill (talk) 11:37, 14 October 2024 (UTC)

@DuncanHill: And now? Polygnotus (talk) 12:46, 14 October 2024 (UTC)
@Polygnotus: Works as expected now, thanks. DuncanHill (talk) 23:50, 14 October 2024 (UTC)
Navigation pop-ups doesn't have access to the result of parsing the wikitext but makes its own primitive analysis of the source text. It can detect file syntax and certain common infobox parameters like image and logo, but apparently not image1. Unlike Page Previews, it can select images outside the lead. PrimeHunter (talk) 14:30, 14 October 2024 (UTC)
It would only require adding |image1 to this line in MediaWiki:Gadget-popups.js:
			'image|image_(?:file|skyline|name|flag|seal)|cover|badge|logo'
PrimeHunter (talk) 14:39, 14 October 2024 (UTC)

Mysterious newline

At Wikipedia:Contents/Mathematics and logic § Glossaries, there's an unintended newline between Algebraic geometry and Algebraic topology. Looking at the source (Wikipedia:Contents/Glossaries/Mathematics and logic), there's a newline between all the entries, but all of them are ignored on the subpage, and all but the first are ignored when it's transcluded. Inspecting Wikipedia:Contents/Mathematics and logic in my browser, the first entry is outside the <div> that holds all the other entries. (And I've checked that this isn't skin-specific or browser-specific.) I've tried putting <nowiki /> at the start of Wikipedia:Contents/Glossaries/Mathematics and logic, because I vaguely remember a bug like that, but no dice. Does anybody know what's going on here? jlwoodwa (talk) 00:33, 15 October 2024 (UTC)

I made the list use actual wikitext list formatting like the other sections. It was using bullet characters with line breaks, which may or may not work, as you saw. Does normal formatting work for you? – Jonesey95 (talk) 00:54, 15 October 2024 (UTC)
Thanks, that did it. No point in debugging something if it's automatically solved by upgrading to semantic list markup. jlwoodwa (talk) 01:11, 15 October 2024 (UTC)

What is happening at Wikipedia:Administrators' noticeboard/Incidents? Of the last 100 edits 62 are tagged as having added disambiguation links - from random checking, most didn't?
The first edit that has it was this, which did add a disambiguation link (MOS:CONSISTENCY). – 2804:F1...D2:B7E7 (talk) 19:57, 14 October 2024 (UTC)

MOS:CONSISTENCY is a redirect to the disambiguation page Wikipedia:Consistency. MOS is a namespace here at the English Wikipedia while [[MOS:CONSISTENCY]] at other wikis would have been an interlanguage link to https://mos.wikipedia.org/wiki/CONSISTENCY. Maybe this confuses a piece of software. PrimeHunter (talk) 20:39, 14 October 2024 (UTC)
I've changed it to bypass the redirect, see if that works. – 2804:F1...D2:B7E7 (talk) 21:02, 14 October 2024 (UTC)
It worked. Your edit [10] was the last to be tagged, and the page still says [[WP:Consistency|MOS:CONSISTENCY]] many edits later. PrimeHunter (talk) 21:38, 14 October 2024 (UTC)
So it did. I'm guessing it isn't happening here because you also linked the redirect target ... interesting. – 2804:F1...D2:B7E7 (talk) 21:41, 14 October 2024 (UTC)
Talk:Redhead (bird) also links MOS:CONSISTENCY and was tagged when it was added.[11] I made two dummy edits without triggering the tag so it seems hard to guess when it will be tagged. PrimeHunter (talk) 01:21, 15 October 2024 (UTC)
That's true. I also noticed at ANI that it had started tagging every edit, but after the bot archived 5 sections (diff), only every other edit or so was tagged. In that edit the bot removes some :MOS links, which, coincidentally, were made :MOS because a bot thought they were accidental language links.
Seems to be some combination with other unknown factors. – 2804:F1...D2:B7E7 (talk) 01:47, 15 October 2024 (UTC)
I'm guessing it's a bug in mw:Extension:Disambiguator, since it's what sets the disambiguator-link-added tag. jlwoodwa (talk) 00:42, 15 October 2024 (UTC)
The relevant function is onLinksUpdateComplete. jlwoodwa (talk) 00:49, 15 October 2024 (UTC)
(To be precise, I mean a bug either directly in that extension, or in its dependencies.) jlwoodwa (talk) 00:51, 15 October 2024 (UTC)

Newspapers.com

I've not been able to log in to Newspapers.com since February because I have free account there linked to my paid Ancestry account. I was told it was very hard to maintain that, for very good reasons. I found it very difficult to edit articles because I depended on Newspapers.com for sources. Now I don't even see it as an option in the Library anymore. Have we totally given up on that? I see Ancestry in the library. Is there some way to access newspapers.com for articles that aren't obituaries? I hope I'm asking this in the right place. Oona Wikiwalker (talk) 01:09, 15 October 2024 (UTC)

Have you applied for access as instructed here? Nardog (talk) 02:31, 15 October 2024 (UTC)

Module:Nihongo and Module:Lang

Hey there. It looks like Japanese sword is having a Lua error. I am guessing that this may have to do with recent changes to either Module:Lang or Module:Nihongo. I can't edit those anyway, but maybe someone here has the ability and/or the ability to test what is going here. Sumurai8 (talk) 15:34, 13 October 2024 (UTC)

Yup, something is wrong with Module:Nihongo. Many Nintendo-related articles are affected. Anyone with technical knowledge able to fix this? QuicoleJR (talk) 15:54, 13 October 2024 (UTC)
Update: Everything is working properly now. Thank you, Trappist the monk, for fixing the module. QuicoleJR (talk) 16:14, 13 October 2024 (UTC)
I am still seeing this on mobile with Module:Lang. It seems to only affect articles after it was changed to langx. "Lua error in Module:Lang at line 1422: attempt to concatenate a nil value" Mellk (talk) 17:05, 13 October 2024 (UTC)
WP:NULLEDIT is your friend.
—Trappist the monk (talk) 19:25, 13 October 2024 (UTC)
Thanks. I suspected it was something to do with the cache. Mellk (talk) 07:13, 15 October 2024 (UTC)

How can I edit an article in full screen, not a column with preview to the left

I want to have to click preview to preview and have the full edit field available. Thanks. Doug Weller talk 12:16, 15 October 2024 (UTC)

Ignore, figured it out. Doug Weller talk 12:21, 15 October 2024 (UTC)

This tool does not work. Is there any analogue? Kaiyr (talk) 18:54, 13 October 2024 (UTC)

@Kaiyr: Do you mean that you couldn't reach the site? Or that there was a server error? It currently appears to be online. Polygnotus (talk) 13:36, 15 October 2024 (UTC)
Ah when I click "Do it!" it says Server(ServerError { code: 1054, message: "Unknown column 'lt0.lt__namespace' in 'where clause'", state: "42S22" }).
You should probably report that issue over at https://github.com/magnusmanske/petscan_rs/issues Polygnotus (talk) 13:37, 15 October 2024 (UTC)

Enhanced editnotice loader

I worked on a module that would serve as an enhanced editnotice loader for Wikipedia. See testwiki:Module:Editnotice_load and Module:Editnotice load (which is an exact copy). Features include category editnotices, better group notices, and editnotices by page ID (which would reduce the need to move pages around).

I want to get further feedback on this loader before it inevitably gets implemented. Please check out the testwiki. It should be backwards compatible with the way we do things, but I would like checks for this first.

If this is to be implemented, there will need to be a couple of changes made, including to:

This would make the editnotice loader much more robust.

Immediately, in preparation for this, I would consider adding the following category editnotices templates:

{{BLP editintro}}

{{Disambig editintro}}

Anything else? Awesome Aasim 19:06, 9 September 2024 (UTC)

Some documentation on how it works from a user's perspective would be helpful, in order to understand the context and how it would be used in practice, including how security restrictions are enforced. On a side note, I'm not sure that its deployment is "inevitable". isaacl (talk) 22:03, 9 September 2024 (UTC)
I have some testcases on testwiki. For best results, view when logged out and inspect the HTML when logged in.
testwiki:Taylor Swift should be a good example of me getting category editnotices working. testwiki:Protected title and testwiki:Protected title2 show the protection editnotice on both the create screen and on the "does not exist" screen when a title is protected from creation for other reasons.
testwiki:Special:EditPage/A should show the page notice from testwiki:Template:Editnotices/PageID/54370 (which is for A). You can also see I renamed previous "page notice"s to "title notice"s because the way page notices are bound to currently are actually to titles, not pages. The new "page notice" will remain bound to a specific page because it uses PageID. There will be no need to update the title notices for pages that exist. On the other hand, for pages that don't exist, the title notice will need to be kept up to date. Awesome Aasim 04:01, 10 September 2024 (UTC)
I can't tell from the article page how to use the feature: where the edit notice lives, how will access be limited, and so forth. Thus it's hard to evaluate the feature without knowing the maintenance cost. isaacl (talk) 09:58, 10 September 2024 (UTC)
The editnotices live in the same pseudo-space: Template:Editnotices/. See testwiki:Module:Editnotice load/config.
I also moved the editnotice links to a collapsible box because the number of creatable editnotices has gotten relatively high after adding category notices. Awesome Aasim 13:16, 10 September 2024 (UTC)
OK, I see there's now a link above the edit notice point to its location, so category-based notices are grouped under a "Category" subpage. What are the enhancements for the group-based notices? isaacl (talk) 18:33, 10 September 2024 (UTC)
There is less ambiguity in how they are handled. For example, on testwiki:Template:A/B/C/D/E, there are five different group editnotices that can be created. So if there is a page where it is desirable that the group Template:A/B needs one group notice, and Template:A/B/C needs another group notice, and Template:A/B/D needs another group notice, that can now be done; there will be one common group notice and two separate group notices for subpages. Awesome Aasim 19:21, 11 September 2024 (UTC)
I would suggest to phase the rollout into stages, and creating a test plan to ensure nothing regressed. Editing this many interface pages and fully protected templates at once sounds like too much work for an admin to volunteer to. For instance, the specific category editnotices you mention can be left for later as we already have a decent system to handle those categories.
Immediately, in preparation for this, I would consider adding the following category editnotices templates this cannot be done immediately as they also need to be removed from Module:Mainspace editnotice, else they would show up twice when the rest of the changes are deployed. – SD0001 (talk) 08:01, 10 September 2024 (UTC)
I actually think this might be something that is better done all in one go. Removing the two category editnotices from Module:Mainspace editnotice should be kind of a no-brainer after the rollout. The way that the module currently does these checks, checking the unparsed wikitext, currently sucks.
Do you have an idea for a Scribunto test runner for Module:Editnotice load to ensure that everything works with demo editnotices? Awesome Aasim 16:53, 13 September 2024 (UTC)

I haven't noticed any bugs or regressions yet, if someone could take a second look at my code maybe then we will be able to identify potential problems. Awesome Aasim 12:52, 2 October 2024 (UTC)

I submitted an edit request. I think this is something that could be botted by an admin opening up 8 edit windows and then saving all of the proposed changes at once. I have done this before, it gets annoying when you get rate limited but it is not impossible. Awesome Aasim 20:05, 8 October 2024 (UTC)

how do I restore the copy-paste function to the edit window? (dvorak keyboard)

Tracked in Phabricator
Task T62928

This changed just recently. I first noticed it on Wikt-en, and at the time I had no problem on WP-en, but now it's spread here. It occurs on some other language wikis, like Wikt-ja, but not on Wikt-vi. In the edit window of a WP article or talk page, if I hit control-x I get bold formatting, with control-c I get italic, and with control-v I get superscript. Presumably this has something to do with me using a dvorak keyboard (dvorak x and c correspond to qwerty b and i), but other commands are unaffected. E.g. control-z and -y are still 'undo' and 'redo', despite corresponding to the qwerty keys for t and /. That means that I can't use the keys with qwerty x c v printed on them for cut-copy-paste, because they continue to act as dvorak q j k and either quit the browser or take me to the URL. It doesn't affect normal typing in an edit window, only commands where the 'ctrl' key is used.

This does not happen when I 'respond' to a thread on a talk page, so that a new window opens: Then all keys act as dvorak, both here and on wikt. The skin also does not seem to be the issue. Here I use Monobook, on Wikt I use Vector 2022. I tried Vector legacy on Wikt and the behaviour was the same.

Can I do something with my css to override this behaviour? — kwami (talk) 00:29, 14 October 2024 (UTC)

The patch that broke it is reverted and going out on the next train on Thursday. phab:T62928 You can turn on syntax highlighting to work around it for now. Izno (talk) 00:47, 14 October 2024 (UTC)
Thanks!
Syntax highlighter is good fix in the meantime. — kwami (talk) 01:27, 14 October 2024 (UTC)

Keyboard shortcuts broken for alternative keyboard layouts (macOS, Safari)

For the last couple days, when editing an article and press 'Command-V' to Paste, the text below is inserted instead:

<sup>Superscript text</sup>

When I 'Command-C' to Copy, double single quotes are wrapped around the selected text.

''selected text''

Strangely, when editing THIS PAGE the shortcuts are working fine. But If I got to edit an article or talk page in mainspace, they do the above.

NOTE: macOS, Safari. I type using the Dvorak keyboard layout. Dvorak's C is in the same location as QWERTY's I. The italics issue above leads me to believe the shortcuts have been (recently) hardcoded to the QWERTY locations rather than taking the actual key/letter typed.

Does anyone know what could be wrong or have a better venue to raise this?

PK-WIKI (talk) 16:49, 15 October 2024 (UTC)

See above. — xaosflux Talk 16:51, 15 October 2024 (UTC)


Unable to use the visual editor for a specific article

For some reason the visual editor is not working on this article. getting the message "sorry this element can only be edited in source mode for now".

Why might this be the case?

Is this normal or is there a problem that has to be fixed? i was told to try clearing my cache and fit that didn't work to ask here.BruceSchaff (talk) — Preceding undated comment added 20:33, 15 October 2024 (UTC)

Should be fine now. Someone had added some bold that doesn't work in the way it was added. Izno (talk) 20:48, 15 October 2024 (UTC)

Template:Wikipedia stats issue

The template seems to be having issues with "mos" as a parameter, possibly due to the MOS namespace or related changes. Could someone please take a look at it? In particular, it's used on Wikipedia:List of Wikipedias, and the issue is visible if you uncomment that row of the table. Thanks. Daniel Quinlan (talk) 00:55, 16 October 2024 (UTC)

It's indeed the MOS namespace which caused problems. I have modified {{Wikipedia stats}} to link the mos wiki as m:mos: which works via a redirect at meta.[12] It's a hack but it works so I have uncommented the mos row.[13] I don't know whether it's possible to make a wikilink which goes directly to the mos wiki. PrimeHunter (talk) 01:42, 16 October 2024 (UTC)
phab:T363538 included a proposal for a mos-x-deconflict: interwiki, but (judging by how that's a redlink) it doesn't currently exist. Special:Interwiki doesn't show any other prefixes for https://mos.wikipedia.org, so I think m:mos: is the only solution for now. jlwoodwa (talk) 01:59, 16 October 2024 (UTC)
That was the solution I originally went with (and coded up). The WMF decided to instead embrace the concept of a namespace and an interwiki having the same name, rather than working around it. * Pppery * it has begun... 02:04, 16 October 2024 (UTC)
Part of that included adding parser functions to explicitly indicate you wanted the interwiki link, but that part hasn't been code reviewed yet. * Pppery * it has begun... 02:05, 16 October 2024 (UTC)
Thanks! Daniel Quinlan (talk) 02:29, 16 October 2024 (UTC)

Accounts with no visible creation date on their contribs page

When I visit the contributions page of a user, it shows their account's creation date at the top. But some, like Dennis Brown and Muboshgu, don't. Why? Avessa (talk) 14:10, 15 October 2024 (UTC)

Because those users were created before user creation times were being logged. —TheDJ (talk • contribs) 14:20, 15 October 2024 (UTC)
But your account was created seven months earlier than Muboshgu's (21 April 2005 vs. 22 November 2005), and yet the creation date is visible on your contribs page. Then there are also Bearcat (created on 3 October 2003), BD2412 (20 February 2005), Koavf (5 March 2005), etc, which all were created before Muboshgu's account too, and yet have their creation date visible. Avessa (talk) 15:23, 15 October 2024 (UTC)
Strange things sometimes occur with logins created before WP:SUL went live in May 2008. --Redrose64 🌹 (talk) 16:18, 15 October 2024 (UTC)
I think the "creation date" for early accounts is a later guess that was added to the database at some point (I remember that it was not there in the beginning; for me, the date given is the date of my first edit, which is probably correct). The list of users by user ID claims to be "by creation date" but that is clearly incorrect. —Kusma (talk) 16:52, 15 October 2024 (UTC)
@Kusma: well it is by creation date ... in terms of the current database, which was implemented in January 2002 with the Phase II software. The previous UseModWiki login system was quite different, as described at the Wikipedia FAQ on the Nostalgia Wikipedia. Graham87 (talk) 01:58, 16 October 2024 (UTC)
The sorting is by actual creation date, not by the date given as "creation date". —Kusma (talk) 08:12, 16 October 2024 (UTC)
The user_registration column wasn't added until MediaWiki version 1.6, which was released on April 5, 2006. There's a script that backfills the column with each user's first edit, but - as best as I've been able to reconstruct - it apparently hasn't been run on enwiki since at least August 24, 2006. Users who registered before 1.6's deployment but didn't edit until after the last time the update script was run still have empty registration times. —Cryptic 16:52, 15 October 2024 (UTC)

Redlinked category

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

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

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

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

XTools seems to be down again

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

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

Text fragments

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

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

Infinite JS errors?

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

 Javascript Error

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

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

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

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

I made a userbox draft

This user tries to reduce Gender bias on Wikipedia.

,

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

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

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

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

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

Problem with cite web

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

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

Lua errors

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

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

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

Search says it found 6 pages but only shows 5?

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

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

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

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

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

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

RoySmith (talk) 17:34, 17 October 2024 (UTC)

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

Keep getting logged out

Tracked in Phabricator
Task T372702

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

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

Hindustan Times

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

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

Add buttons to Reply Tool

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

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

Getting different fonts into wikipedia

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

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

below are some free licensed sinhala fonts:

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

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

Is there evidence suggesting Template:no spam works?

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

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

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

Images looping

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

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