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}} → 20241006081446
    {{#time: H:i, j F Y (e)|{{REVISIONTIMESTAMP:London}}}} → 08:14, 6 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:+4,[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. ^ "Carbon: Binary compounds". Retrieved 2007-12-06.
  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)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_216&oldid=1251321138"