Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Nirmos (talk | contribs) at 14:18, 2 January 2020 (→‎Recent changes isn't loading). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk.


File display problem with green on black gadget

I use the green text on a black screen gadget (available in Preferences), as it makes Wikipedia less painful to look at for extended periods of time. The logo File:Lewes Priory School logo.png appears to contain mainly black images on a transparent background, so to me it all looks black, except for a handful of random white lines and blobs. Is it possible for the file to be edited in some way so as to make it visible to users of the gadget? Thanks, DuncanHill (talk) 20:48, 23 December 2019 (UTC)[reply]

@DuncanHill: Yes, it is, but since the issue affects a lot of images with transparent backgrounds it would probably be better to change the gadget so that it doesn't have this issue. Alternatively, if you just want to fix it for yourself, you could add a line of CSS to your common.css page, probably something resembling .mw-parser-output img { background-color: #fff }. (Do note that this will introduce a white background for all images with transparency.) Jc86035 (talk) 08:01, 27 December 2019 (UTC)[reply]
@DuncanHill: Choosing appropriate color(s) for a logotype is an important part of a logo design process – see notes at Logo#Logo color. Sometimes companies and other organizations prepare several versions of their logo for use in different color environments (e.g., for black-and-white media with white or with black background; for gray-scale or for multicolor media with light or with dark background). Those versions may have a background added or appropriate contour lines in a color depending on an expected neighborhood. So, there is no simple way to just edit a logo file to make it compatible with an arbitrary environment. The more because a logo is a property of some organization and only they are entitled to choose a new shape, color or contour for their logo. --CiaPan (talk) 16:25, 27 December 2019 (UTC)[reply]
@CiaPan: The version of the logo we have is not what appears on the school website, it appears to be a negative image. DuncanHill (talk) 16:31, 29 December 2019 (UTC)[reply]
@DuncanHill: I see. But maybe eleven years ago, when the file was fetched, the school's website was black on white, like Wikipedia is...?
Anyway, replacing a black-and-white logo with its inverse everywhere is quite safe (you don't risk a change of meaning) and quite simple (it needs just replacing a file). But adjusting an image to both light and dark theme is another thing: it requires either adding appropriate background in the image itself, which will join smoothly with one theme's background and make an appropriate buffering space in the other one; or keeping two or more versions of a file and dynamic supplying appropriate one for a detected theme. One solution is quite artificial and too simple to be good (what if a third theme appears?), the other one is IMHO next to impossible due to a palette detection needed at the client side and lacking method of identifying required versions of an image.
Shortly, I think the best solution (short, safe and quite easy) is adding a background to the image in the default Wikipedia background color. Possibly a gadget might add it, as Jc86035 suggests above. --CiaPan (talk) 20:31, 29 December 2019 (UTC)[reply]

What would you call this?

This is a stupid question, but I saw someone add this to an article: *𝓐𝓷𝓪𝓰𝓱𝓪 𝓼𝓪𝓷𝓳𝓮𝓮𝓿 𝓪𝓼 𝓶𝓪𝓱𝓲𝓶𝓪(𝓮𝓹𝓲𝓼𝓸𝓭𝓮 182). How would you technical types describe this? Unicode font? ASCII font? How does one generate this sort of thing? Thanks, Cyphoidbomb (talk) 20:19, 24 December 2019 (UTC)[reply]

It's using the Mathematical Alphanumeric Symbols part of Unicode. Although popular on social media, this shouldn't be used outside of the proper mathematical context since it's not accessible to people using screenreaders. the wub "?!" 20:54, 24 December 2019 (UTC)[reply]
Naturally! Thanks for the explanation, wub! Cyphoidbomb (talk) 21:21, 24 December 2019 (UTC)[reply]
Looks like there are editors who have used some of these characters in their sigs, according to a search of Wikipedia namespace for "𝓮" AND insource:/[𝐀-𝟿]{3}/. Any idea how to do a search that won't time out to find these in article space? —[AlanM1(talk)]— 14:09, 25 December 2019 (UTC)[reply]
Use Quarry, it runs on database dumps. --qedk (t 桜 c) 20:57, 26 December 2019 (UTC)[reply]
Quarry does not have access to page text. * Pppery * it has begun... 22:43, 26 December 2019 (UTC)[reply]

Edit box

Hi, Anyone have an idea why my edit box is like this ?,
It all loads as black but then changes to purple (for articles) or grey/big headers (for talkpages),
Thanks, –Davey2010Talk 21:07, 25 December 2019 (UTC)[reply]

@Davey2010: You have syntax highlighting enabled - the pencil button just left of "Advanced" in the toolbar. Click it again to disable, although personally I find it quite helpful. The purple in the article screenshot is marking templates. the wub "?!" 22:35, 25 December 2019 (UTC)[reply]
You're a star the wub thanks so much! :). –Davey2010Talk 22:50, 25 December 2019 (UTC)[reply]

Template_talk:Infobox_person#Residence_parameter

Hi all, can someone with template experience please look at this discussion and remove |residence=? I'm not sure what else needs to happen, but I'd imagine that a bot needs to remove the content somehow? Can someone please look into that. I've no experience with this. Thanks, Cyphoidbomb (talk) 03:08, 26 December 2019 (UTC)[reply]

It has been removed/commented out already from the template. Removing it from articles altogether is a task for Wikipedia:Bot requests. – Ammarpad (talk) 06:25, 26 December 2019 (UTC)[reply]

Table column width

Hello, could some kind person please tell me how to make the column widths the same size here? Thank you in advance, SandyGeorgia (Talk) 23:00, 26 December 2019 (UTC)[reply]

 Done, thanks Izno! SandyGeorgia (Talk) 23:26, 26 December 2019 (UTC)[reply]

"Hide registered users" toggle at Special:NewPages

Tracked in Phabricator
Task T241495
Tracked in Phabricator
Task T238483

The toggle "Hide registered users" at Special:NewPages does not seem to be working properly. While it is possible to hide patrolled edits, bots, and redirects, this toggle does not produce the expected effect of hiding registered users and thus displaying only IP creations (i.e. when I click it, there is no visible change to the pages shown in the feed, unlike the other three toggles). To reproduce, go to Special:NewPages and experiment with these four toggles on the bottom—the plainly labeled one on the far left seems not to be working. Purging the page and using different settings elsewhere in the "New Pages" box do not have any effect. Is there a different intended function, or is this a bug? Thanks in advance. ComplexRational (talk) 16:57, 27 December 2019 (UTC)[reply]

@ComplexRational: this appears to be a bug, being tracked at: phab:T241495. Thank you for the report. — xaosflux Talk 17:37, 27 December 2019 (UTC)[reply]
Upmerged to phab:T238483. — xaosflux Talk 17:41, 27 December 2019 (UTC)[reply]

Search function errors ... "too busy"

Seems this error has been happening a lot recently: "An error has occurred while searching: Search is currently too busy. Please try again later.". Any idea what is causing this, and if there is any work happening in the background to resolve this? Steel1943 (talk) 17:54, 27 December 2019 (UTC)[reply]

"High lag on CirrusSearch". Tech Ops is already on it. Whatamidoing (WMF) (talk) 21:38, 27 December 2019 (UTC)[reply]

search too busy?

(Attached to existing discussion.) ―Mandruss ☎ 06:28, 28 December 2019 (UTC)[reply]

WHy have I been getting the following error from the search bar "An error has occurred while searching: Search is currently too busy. Please try again later."-TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 04:10, 28 December 2019 (UTC)[reply]

Tony, see the post a few threads above. --GoneIn60 (talk) 05:58, 28 December 2019 (UTC)[reply]

Template: Infobox roller coaster

Resolved

--qedk (t 桜 c) 08:17, 28 December 2019 (UTC)[reply]
Looking for a template guru...

At Template:Infobox roller coaster, there are speed parameters (one for mph and one for km/h) that when used will list an auto-conversion from one unit to the other in parenthesis. So for example, if speed_mph = 55 is specified, the infobox will display 55 mph (89 km/h). The problem is that when high values are used, this conversion becomes less concise. An example can be seen at Formula Rossa. 240 km/h is being converted to 150 mph in parenthesis, but multiple sources (including Guinness World Records) list it precisely as 149.1 mph.

The solution is to use the |sigfig=4 parameter with the convert template which isn't currently being done. I wasn't sure how to edit the template to include this for higher numbers only. We wouldn't want 50 km/h to start displaying 31.07 mph, for example. I was thinking only numbers greater than say 165 km/h should use this sigfig parameter (meaning coaster that exceed 102 mph, which isn't many). Does anyone know how to code that? Another option would be to introduce a hidden flag that can be specified when you want the extra precision. Open to ideas here, thanks in advance! --GoneIn60 (talk) 20:38, 27 December 2019 (UTC)[reply]

You can add sigfig parameter and pass it through to {{Convert}} template. Ruslik_Zero 20:58, 27 December 2019 (UTC)[reply]
Looks like QEDK added the sigfig parameter to the infobox, so that it can be manually specified when needed. That's a great start, so thanks for that! I may tweak it further so we can do the same for other fields like track length, drop, and height. Maybe have sigfig_speed, sigfig_height, etc. --GoneIn60 (talk) 22:13, 27 December 2019 (UTC)[reply]
@GoneIn60: Added |sigfig= as a default parameter to fall back on for an infobox, with each data values having their own sigfig parameters (per your suggestion). --qedk (t 桜 c) 08:17, 28 December 2019 (UTC)[reply]
Thanks again for all your help. Per the advice below, I may roll those changes back considering there is a workaround without adding the complexity to the template. But at least I know how to use this option now. Greatly appreciate your time! --GoneIn60 (talk) 20:41, 28 December 2019 (UTC)[reply]
Note that for this case you could have just specified the speed_km/h as "240.0", for which {{convert}} will calculate the correct number of significant figures: 240.0 km/h (149.1 mph). With this example you can also specify three significant figures by entering the speed as "240.": 240 km/h (149 mph). But sigfig would be necessary to specify 3 significant figures for a value like "2400000", as Module:Convert doesn't seem to support anything like the overline or underline notations mentioned at Significant figures#Significant figures rules explained. Anomie⚔ 14:08, 28 December 2019 (UTC)[reply]
Anomie, I didn't realize that could be done. I tested, and it works like a charm. Thanks! --GoneIn60 (talk) 20:41, 28 December 2019 (UTC)[reply]

User:Abelmoschus Esculentus/AjaxRollback.js

This script no longer works... --Thegooduser Life Begins With a Smile :) 🍁 03:37, 28 December 2019 (UTC)[reply]

Hi Thegooduser, the user has sadly retired. A new script can be found at User:DannyS712/AjaxRollback. Does that one work? ~ ToBeFree (talk) 03:43, 28 December 2019 (UTC)[reply]
Oh, that's why it don't work! Thanks! --Thegooduser Life Begins With a Smile :) 🍁 03:47, 28 December 2019 (UTC)[reply]
Hmm, not necessarily, now that I compared the two scripts. See Special:ComparePages?rev1=886050072&rev2=876272571.
Your User:Thegooduser/common.js currently contains a huge number of other scripts. Could you try removing them all to see if that solves the problem? If so, please re-enable them one by one to see where the actual problem is. ~ ToBeFree (talk) 03:51, 28 December 2019 (UTC)[reply]
The script doesn't seem to work for me (neither does User:Writ Keeper/Scripts/massRollback.js, incidentally..) Although I have so many scripts/configurations on my account, that I can't be sure that a conflicting script isn't the issue. Galobtter (pingó mió) 08:26, 28 December 2019 (UTC)[reply]
@Galobtter: mass rollback still works for me --DannyS712 (talk) 08:32, 28 December 2019 (UTC)[reply]
@Thegooduser: Should work now --DannyS712 (talk) 08:38, 28 December 2019 (UTC)[reply]
@DannyS712: @ToBeFree: Working now, thanks guys! Thegooduser Life Begins With a Smile :) 🍁 21:08, 28 December 2019 (UTC)[reply]
Side note: When you have a lot of scripts in your account (not to mention gadgets), the cycle of removing all, clearing your web browser's cache, re-enabling one, testing, and then re-enabling the next, can take a couple of hours. (Then you'll discover that you forgot about your global scripts at Meta, and have to do it all over.) A Binary tree system can be useful: Disable all, and test. If the problem goes away, then one of those scripts is the problem. Re-enable half, and test. If the problem returns, then something in that half is the problem. If it doesn't, then the problem is in the other half. You can keep repeating by halves until you've narrowed it down to the culprit. If you have, say, 16 user scripts, and one is broken, then working by halves always finds the problem in four steps, whereas testing each individually finds the problem in an average of eight rounds. Whatamidoing (WMF) (talk) 17:22, 30 December 2019 (UTC)[reply]

Cannot find hatnotes displayed anywhere in iOS app

I have the Wikipedia iOS app on my phone. Hatnotes are entirely missing now. They used to be below the lede. Before I do things like create a Phabricator account and read scores of pages of documentation, my question here is, do others have this problem too? I hope no one wiped them out intentionally. If the latter is true then the justification has to be explained at Wikipedia talk:Hatnote. Quercus solaris (talk) 04:10, 28 December 2019 (UTC)[reply]

This is phab:T240721, which for some reason has been triaged as "low" priority. Galobtter (pingó mió) 06:51, 28 December 2019 (UTC)[reply]
How do we get the priority raised on that? It seems like a pretty big deal to me. SchreiberBike | ⌨  18:42, 28 December 2019 (UTC)[reply]
The general process is to login to Phabricator (login page here) using the same username/password you use for the wiki. Then go to the particular task page (i.e. phab:T240721), where you can add a comment in the text box near the bottom of the page, then click Submit. Just explain, like you did above, why you feel this needs a higher priority. The folks who work on these things may or may not change the priority, but that's the process to let your voice be heard. If you prefer, ping me and I can handle it for you. -- RoySmith (talk) 19:05, 28 December 2019 (UTC)[reply]
Thanks @RoySmith: I've given it a try. SchreiberBike | ⌨  21:32, 28 December 2019 (UTC)[reply]
Looks like you figured it out. -- RoySmith (talk) 22:09, 28 December 2019 (UTC)[reply]

Continuous editing conflict (cross-post from help desk)

Cross-posting report of a technical issue on the help desk in the hope someone with technical know-how can assist. Please reply to the original post to keep discussion focused. – Teratix ₵ 09:52, 28 December 2019 (UTC)[reply]
At 04:49, 19 August 2019 (UTC), I came to ask for help because often when I saved edits I got a false "edit conflict" warning. I discovered that several other editors had the same problem. Please see Wikipedia:Help desk/Archives/2019 August 19#Continuous editing conflict. I edit Wikipedia using Google Chrome (up-to-date) running under Win 10 Pro (also up-to-date); nothing exotic. The problem for me has escalated from frequent to constant. It is a real handicap in editing Wikipedia because it wastes a lot of my time. I do not have any beta gadget enabled and my broadband connection is fast enough. I would appreciate help with this problem in editing Wikipedia. Thank you.

EditCounterOptIn.js?

Cleaning up old crap, I discovered I had created User:RoySmith/EditCounterOptIn.js back in 2011. I vaguely remember there was some optional service that this enabled. Does it still do anything useful? -- RoySmith (talk) 16:22, 28 December 2019 (UTC)[reply]

There was once a tool that got activated by that type of page but it seems like it got folded into the general XTools. Jo-Jo Eumerus (talk) 16:27, 28 December 2019 (UTC)[reply]
See m:Requests for comment/X!'s Edit Counter and Wikipedia:Village pump (proposals)/Archive 111#Edit Counter Optin for some background. Opt-in was removed here on the English Wikipedia, but is still relevant for at least some other wikis. Anomie⚔ 16:43, 28 December 2019 (UTC)[reply]
X!'s Edit Counter (formerly Soxred93's edit counter) was altered in early 2010 so that the full stats, previously visible for all users, became hidden unless the user voluntarily made them public by creating Special:MyPage/EditCounterOptIn.js (for one project) or m:Special:MyPage/EditCounterGlobalOptIn.js (for all projects). The content of the page didn't matter: the report merely tested for its existence. More at Wikipedia:Village pump (technical)/Archive 73#Toolserver Opt-in Requirement and User talk:X!/Archives/04/2010#Wheres the month counters??? --Redrose64 🌹 (talk) 17:14, 28 December 2019 (UTC)[reply]

lua check

If anyone has a min to help debug a lua error on meta-wiki, please take a look at meta:Module talk:Project portal. Thank you! — xaosflux Talk 16:59, 28 December 2019 (UTC)[reply]

Display problem in Template:ConfirmationOTRS

Today a {{ConfirmationOTRS}} template was placed here with the parameter |license=CCBYSA 4.0 International . That was a good-faith mistake by the agent, who I imagine did not know that that licence is not compatible here, and will I'm sure be resolved. What matters to me here is the behaviour of the template, which ignored the license parameter provided to it, and displayed CC BY-SA 3.0 instead. It looks to me as if it's designed to do that. Wouldn't it be much more useful if it displayed an error message if the licence is CC BY-SA 4.0? Could that easily be made to happen? Justlettersandnumbers (talk) 18:55, 28 December 2019 (UTC)[reply]

This is the code: 
{{#switch:{{lc:{{{license|}}}}}
 |pd|cc0|Public domain|public domain = into the public domain.
 |g = Under the [[Wikipedia:Text of the GNU Free Documentation License|GNU Free Documentation License]]. Because this permission was received prior to 1 November 2008, you may use the material under either that license or the Creative Commons Attribution-ShareAlike 3.0 Unported license.
 |gfdl|dual|d|both = under both the [[Wikipedia:Text of Creative Commons Attribution-ShareAlike 3.0 Unported License|Creative Commons Attribution-ShareAlike 3.0 Unported license]] and the [[Wikipedia:Text of the GNU Free Documentation License|GNU Free Documentation License]]. You may use either or both licenses.
 |cc4|cc-by-sa-4.0 = {{Error|CC BY-SA 4.0 is not a [[WP:Compatible license|compatible license]].}}
 |cc|cc3|cc-by-sa|cc-by-sa-3.0|#default = under the [[Wikipedia:Text of Creative Commons Attribution-ShareAlike 3.0 Unported License|Creative Commons Attribution-ShareAlike 3.0 Unported license]].
 |attribution = for anyone to use it for any purpose, provided that the copyright holder is properly attributed. Redistribution, derivative work, commercial use, and all other uses are permitted. 
 |cc-by-3.0 = under the <span class="plainlinks">[https://creativecommons.org/licenses/by/3.0/ Creative Commons Attribution 3.0]</span> license.
 |cc-by-4.0 = under the <span class="plainlinks">[https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0]</span> license.
}}
As may be seen, a number of variations on the CC licenses are coded for, including cc, cc0, cc3, cc4, cc-by-3.0, cc-by-4.0, cc-by-sa, cc-by-sa-3.0 and cc-by-sa-4.0; but it has nothing for the (lowercased) value ccbysa 4.0 international - we can't hope to test for every theoretical variation. In such circumstances the fallback is the value for #default so it behaves as if |license=CC-BY-SA-3.0 were specified, which is the Creative Commons Attribution-ShareAlike 3.0 Unported license. If Ganímedes (talk · contribs) were to alter the template parameter from |license=CCBYSA 4.0 International to any of |license=CC-BY-SA-4.0, |license=CC-BY-4.0 or |license=CC-BY-SA-3.0 it would be more explicit. --Redrose64 🌹 (talk) 21:30, 28 December 2019 (UTC)[reply]
Thanks all. The customer has agreed to release the text under CCBYSA 3.0, so no problem anymore. I use to work in Commons and we never has got this problem. I apologize. Regards. --Ganímedes (talk) 00:32, 29 December 2019 (UTC)[reply]
I would support the deprecation of arbitrary values for |license= in favor of a warning to use a more specific license. I ran a quick report on the parameter usage for ConfirmationOTRS and there's a lot of junk in there that doesn't need to be. --AntiCompositeNumber (talk) 06:00, 29 December 2019 (UTC)[reply]

How to challenge the decision to remove support for insecure browsers?

Tracked in Phabricator
Task T238038

I believe Wikimedia's decision to remove support for insecure browsers (recently expanded to include browsers that use old versions of HTTPS) amounts to unintentional discrimination against readers on low incomes and readers in developing countries, who might be stuck using 10-year-old second-hand mobile phones that cannot be upgraded. There is a big difference between asking a prosperous person to upgrade their device and asking a homeless person to do so. This may become more of a cause for concern if public libraries move to a "bring your own device" approach instead of supplying computers, which now seems to be happening in some towns. I understand there are concerns about surveillance, but surely someone who cannot afford the necessary equipment to bypass it should be able to decide for themselves if they'd rather be spied on, instead of having Wikimedia decide that it's better to lose access completely?

I do run a proxy service (read-only, no edits allowed) which can fetch requested pages and return them over plain HTTP. But I cannot afford the traffic that may ensue if I advertise this more widely. I believe Wikimedia should re-enable HTTP from their own servers, as a non-default option with suitable warnings and limitations.

Where should I be posting about this? Silas S. Brown (email, talk) 21:17, 28 December 2019 (UTC)[reply]

@Silas S. Brown: Does Wikipedia:Village pump (technical)/Archive 177#Security warning issues help? --Redrose64 🌹 (talk) 21:34, 28 December 2019 (UTC)[reply]
Thanks but that discussion doesn't seem to shed much light on where to put the above point... Silas S. Brown (email, talk) 22:41, 28 December 2019 (UTC)[reply]
@Silas S. Brown: this isn't a English Wikipedia specific thing, it is across all of the hundreds of WMF projects. The task for it is here: phab:T238038. You can leave feedback on that task. — xaosflux Talk 00:17, 29 December 2019 (UTC)[reply]

Note that the security issues revolve around exploits related to the insecure older protocols. It was the case that where a browser did not support the new protocol, an older one would would be permitted; but this has been exploited to attack systems including WMF's using the old protocols. So the various vendors have reluctantly decided to end all support for the old protocols. So what you are suggesting is the same thing that you are protesting; if the change is not made, anyone who has a newer system (the majority) will become cut off. Hawkeye7 (discuss) 00:40, 29 December 2019 (UTC)[reply]

@Hawkeye7: I think there is at least a case to argue that read-only access shouldn't depend on this (even that read-only access shouldn't depend on encryption at all). — xaosflux Talk 00:44, 29 December 2019 (UTC)[reply]
And yes, I know all sorts of reason that can be a bad idea, put perhaps through some sub domain only (e.g. en.insecure.wikipedia.org , which would be added to the global blacklist, and with an insecure banner or the like on every page). — xaosflux Talk 00:52, 29 December 2019 (UTC)[reply]
The biggest reasons that this isn't a good idea are censorship and privacy. With strong encryption in place, a person-in-the-middle can only see that you've connected to Wikipedia. They can't see what pages you're reading, which means that they also can't block specific pages or silently modify their content: you either get the same Wikipedia as everyone else or you get no Wikipedia at all.
This might not matter to you if you live somewhere where freedom of information is the norm and you aren't concerned about someone looking over your shoulder. It definitely does matter to some people though. Think about the pro-democracy protestor who could be jailed for having the wrong opinions. Think about the people living under a dictatorial regieme that would rather rewrite history than face the past. Think about the officeworker researching an embarassing disease and not wanting anyone else to find out. Think about the closeted gay kid at a school that considers homosexuality to be immoral.
By providing access to Wikipedia without strong encryption, we open these people up to real-life harm. They do not have the choice between HTTP and HTTPS, only the choice between safe and dangerous. Providing an insecure version of Wikipedia means providing no secure version of Wikipedia. --AntiCompositeNumber (talk) 02:03, 29 December 2019 (UTC)[reply]
But, the choice is still there for readers, so long as mirrors still allow plain HTTP connections. And I'm sure some mirrors are operated by people far less well-meaning than Silas S. Brown. None are subject to our privacy policy. That's a far worse option than any WMF-controlled site. Suffusion of Yellow (talk) 02:37, 29 December 2019 (UTC)[reply]
@Suffusion of Yellow: so how about a http-only WMF mirror? — xaosflux Talk 02:41, 29 December 2019 (UTC)[reply]
@Xaosflux: Yes, on the surface that looks like the least bad solution. I wonder if it would be possible, using HSTS, to block only browsers capable of accessing the "secure" site from even sending requests to the "insecure" site. Suffusion of Yellow (talk) 03:01, 29 December 2019 (UTC)[reply]
@AntiCompositeNumber: good points indeed - and I'm not saying this is necessarily a good idea - just that it is a feasible argument. As far as your scenarios go, it has become quite common for your "officeworker" scenario to already be exposed, either though client-side inspection, or forced MITM corporate proxies. Nation-states have begun using forced decryption as well (c.f. Kazakhstan man-in-the-middle attack). The down side is that the choice (including the problem introduced by the original poster) is really between a secure (with the above forced MITM caveats) wikipedia and no wikipedia. — xaosflux Talk 02:41, 29 December 2019 (UTC)[reply]
There's nothing we can do for security when the attacker controls the endpoint device, like in a corporate traffic inspection scenario. While those tools do exist, they don't exist everywhere. They require higher technical competence and more upkeep than a passive inspection tool, putting them out of reach of many organizations. If that example's still problematic, replace "officeworker" with "person" and "anyone else" with "the advertisers your ISP might sell your browsing history to" [1]. When a security system fails, it should fail loudly. No matter how many scary warnings you put on something that's insecure, if people can ignore them, they will [2]. You can't ignore a completely inaccessable site though.
I don't have numbers about how many people are still connecting to Wikipedia using TLS 1.0, but the WMF typically doesn't deprecate a browser unless it accounts for less than 1% of average total traffic. We're not the first to disallow TLS 1.0 connections, websites like nist.gov, gizmodo.com, un.org, nytimes.com, twitter.com, state.gov, github.com, any site that process payment card information... got there first. The choice between protecting our most vulnerable readers from harm or continuing to support browsers and devices with dwindling usage and an already degraded internet experience. --AntiCompositeNumber (talk) 04:05, 29 December 2019 (UTC)[reply]

I suppose even a really old browser could run TLS-in-JS. I have no idea if this is actually a practical solution, i.e. would it be so slow as to be unusable, but it's an interesting idea. -- RoySmith (talk) 03:40, 29 December 2019 (UTC)[reply]

That depends on how you define a "really old browser" (first ones doesn't even supported JS). You can browse in any browser by using Nginx (or something similar [like Fiddler] for http/https conversion) (+ Privoxy [for old browsers without proxy support] for request/response/html rewrite, or by Nginx packaged with Lua [under Windows]). MarMi wiki (talk) 18:16, 29 December 2019 (UTC)[reply]
  • I think the Wikimedia Foundation should write a version of their app that allows older devices to connect by providing their own tls version support. Or they can pressure phone manufacturers to patch their operating systems. Discriminating against the poor just because they have old devices go against Jimbo Wales' quote "i'm doing this for a child in Africa". Poor people need open knowledge the most. 2A01:4C8:F:E3D9:2B73:C9CA:12CF:BCA2 (talk) 19:10, 30 December 2019 (UTC)[reply]

User contributions blank

When I check my user contributions, there are no searches matching my criteria. Does anyone have any solutions? Thanks, Thatoneweirdwikier Say hi 16:19, 29 December 2019 (UTC)[reply]

What are the criterias that you set? Stryn (talk) 16:40, 29 December 2019 (UTC)[reply]
Stryn, I didn't set any criteria. That's what makes it so unusual. Thanks, Thatoneweirdwikier Say hi 16:47, 29 December 2019 (UTC)[reply]
Wow, that was very thick of me. I didn't realise that the 'Hide probably good edits' button was checked. So sorry for wasting your time! Thanks, Thatoneweirdwikier Say hi 16:50, 29 December 2019 (UTC)[reply]
Obviously, you just need to start making more crappy edits -- RoySmith (talk) 17:21, 29 December 2019 (UTC)[reply]

Wrong message at the top of search results?

When I search for "Hillstreet Blues", I do get results for "Hillstreet Blues", but the message above the three results reads "Showing results for hill street blues. Search instead for Hillstreet Blues." This seems wrong. Should it not read "Showing results for Hillstreet Blues. Search instead for hill street blues."? --Bensin (talk) 22:55, 30 December 2019 (UTC)[reply]

Bensin, looks proper to me. It's the same as Google really; search "whatver" and you'll get 

Showing results for whatever
Search instead for whatver

Home Lander (talk) 23:33, 30 December 2019 (UTC)[reply]

But as Bensin said, that's not what it actually does. It behaves like if Google did show results for "whatver" from the start. The search is Special:Search/Hillstreet Blues. The message is MediaWiki:Search-rewritten, documented at translatewiki:MediaWiki:Search-rewritten/qqq. We use the default message. It's only meant to be shown when the search is not what the user entered. Something is wrong but the error appears to be that the wrong search results are shown. It should have shown search results for hill street blues as it incorrectly claims to be doing. PrimeHunter (talk) 23:38, 30 December 2019 (UTC)[reply]
PrimeHunter, OK, I'm following you now. I'm not sure however if it's showing incorrect results or if it's simply detecting the results because they're so similar - try Special:Search/Gargae and you'll get
  Showing results for garage. Search instead for gargae.
The first result is Garage, as expected. Home Lander (talk) 23:46, 30 December 2019 (UTC)[reply]
In that example it behaves correctly and shows results for "garage" as it says. If you click "Gargae" in the message then you get no results. In Bensin's example, you get the same three results as originally if you click "Hillstreet Blues", while "hill street blues" gives thousands of results. Maybe the error only happens if there are a few results on the term the search function guesses is wrong. PrimeHunter (talk) 00:09, 31 December 2019 (UTC)[reply]
Yes, the error is that the message reads "Showing results for hill street blues." when it is actually showing results matching (and bolding) the word Hillstreet. --Bensin (talk) 08:16, 2 January 2020 (UTC)[reply]

hide contribs script stopped working?

For the past couple days it seems like User:Markhurd/hidetopcontrib.js has not been working. It creates a button to hide all contribs that aren't the current version, and it's really handy. Now, however, it hides everything other than edits which are both not the most recent and new page creations (but no, only show edits that are page creations is not selected). Any ideas? — Rhododendrites talk \\ 23:18, 30 December 2019 (UTC)[reply]

@Rhododendrites: Seems to be conflicting with User:Evad37/Thanky.js (your most recently installed script), somehow. Suffusion of Yellow (talk) 20:06, 31 December 2019 (UTC)[reply]
Thanks. @Evad37: Any idea why that might be? (Sadly, I cannot ping Markhurd). — Rhododendrites talk \\ 20:20, 31 December 2019 (UTC)[reply]
@Rhododendrites: Does User:Suffusion of Yellow/hidetopcontrib.js (diff) work for you? Suffusion of Yellow (talk) 21:56, 31 December 2019 (UTC)[reply]
@Suffusion of Yellow: Thanks. It does work, but it's different. When hiding pages that are current, Markhurd's script displayed only my most recent edit to the pages that are not current. Your new version shows all edits to those pages. So if I made 100 edits to an article and then someone else made an edit, it would show all 100 of my edits rather than just the most recent. Would this be a trivial fix? — Rhododendrites talk \\ 17:49, 1 January 2020 (UTC)[reply]
@Rhododendrites: In both versions, that behavior is controlled by the userHideAllSubsequent=true; line. It looks like you commented it out when you switched to mine. If you leave that in, does my version work the same as the original? Suffusion of Yellow (talk) 18:12, 1 January 2020 (UTC)[reply]
Ah! Yes. Good now. Wasn't even thinking about that fairly self-explanatory line. Thanks. :) — Rhododendrites talk \\ 18:18, 1 January 2020 (UTC)[reply]

Good. I'd prefer to not maintain a fork of that script, though. Amorymeltzer, you were the last one to touch User:Markhurd/hidetopcontrib.js. What do you think about this change? I can explain in more detail, if you like. Suffusion of Yellow (talk) 18:49, 1 January 2020 (UTC)[reply]

Forking is probably better, that user has been inactive for 2+ years so others shouldn't rely on their personal scripts. — xaosflux Talk 21:09, 1 January 2020 (UTC)[reply]
Haven't tested since I'm on mobile, but changes seem reasonable — it's a new class and would definitely be better to make use of it. I can check it out more tomorrow. As for the fork/no fork, it's been surprisingly fine; I don't mind making minor changes to support other scripts. IIRC a number of folks used this, so YMMV. ~ Amory (u • t • c) 22:01, 1 January 2020 (UTC)[reply]
Thanks, no hurry. There are 81 imports according to Wikipedia:User_scripts/Most_imported_scripts. Suffusion of Yellow (talk) 22:57, 1 January 2020 (UTC)[reply]

Building infobox how to show map?

How do I show map as in El Templete vs Colegio Nacional de Arquitectos de Cuba when they both have the same info box building template but one does not show the location map no matter what I do?? Help!!!ovA_165443 (talk) 03:20, 31 December 2019 (UTC)[reply]

The second article does not have coordinates in Wikidata. Once they are added there, the map will appear. MB 03:28, 31 December 2019 (UTC)[reply]
Or just fill in |map_type=, like this like this, as explained in the documentation for Template:Infobox building. – Jonesey95 (talk) 06:46, 31 December 2019 (UTC)[reply]
More specifically, like this: Special:Diff/933322170. This will always point at the proper edit, no matter how many new edits appear in history (imagine someone trying to follow your advice in 5 years). --CiaPan (talk) 10:54, 31 December 2019 (UTC)[reply]
Pinging the author I replied to, as well as OP: Jonesey95, ovA_165443. --CiaPan (talk) 11:25, 31 December 2019 (UTC)[reply]
Thank you!!! ovA_165443 (talk) 14:09, 31 December 2019 (UTC)[reply]

Template code and Lua (and MediaWiki messages)

I used to do a lot of complex template coding here on Wikipedia but have now been away for a long time. But now I am back part time (mostly updating/modernising some of my old stuff). So I would like to ask about some of the new things here. I know some of these questions partly come down to opinions, but advice from more up to date editors/coders would be helpful and appreciated.

1: Does Lua modules run much faster on the servers than templates made with only template code? I mean for fairly complex template code. That is, do Lua modules cause less load on the servers?

2: I see people have gone around changing well working templates into Lua code instead. What reasons could there be for that? Is it mostly about speed (server load) or some other reasons? (I don't mean those cases where Lua allowed them to add some complex functions that are hard to do in template code.)

3: Today I added code in a MediaWiki message calling a Lua module. I could have done it with pure template code instead. Is there a preference for MediaWiki messages? (In this case server load could not be an issue since that code only runs when editing user talk pages.)

4: If I can implement something reasonably efficiently but with somewhat tricky hard to understand code in template code, instead of slightly simpler code in Lua, should I then choose template code or Lua? I assume template code is more portable to other wikis, since many other wikis might not be Lua enabled. (I mean MediaWiki wikis outside the Wikimedia Foundation projects.)

5: I assume there still are more coders here that understand template code than understand Lua? I for instance have not learnt Lua and will probably keep coding template code, only calling Lua modules others have built (if a Lua module happens to provide what I need).

I did find Wikipedia talk:Lua but I wanted to ask here where not only Lua enthusiasts hang out. (And I did spend an hour searching trying to find answers to this, but didn't find much. But I suck at searching.)

And happy new year to everybody!

--David Göthberg (talk) 01:11, 1 January 2020 (UTC)[reply]

@Davidgothberg: you may want to join and ask these also at Wikitech-l. You can also learn a bit more about Lua (especially our implementation of it) at mw:Lua. Lua is a fairly easy programming language (it is an interpreted language). — xaosflux Talk 01:56, 1 January 2020 (UTC)[reply]
Variables – so you don't have to reevaluate an expression multiple times; the ability to add copious notes anywhere – can be done but it's a pain; whitespace for readability – not always possible; multiple, callable 'subroutines' all in the same module – callable sub-templates must be separate; import and export functions from and to other modules; huge data tables and the ability to create variants of a data table on an as-needed basis and only once when MediaWiki processes an article even when the template / module has many instances in that article; no doubt there are more reasons to prefer lua.
  1. Don't know and really don't care (I suppose I will when whatever I'm doing runs out of lua time – so far that has only happened when I've done something particularly stupid)
  2. Don't know; I wouldn't if whatever it is works correctly and doesn't need enhancement; I recently updated {{nihongo}} from wikitext to lua so that it uses Module:lang for rendering, adds error detection, categorization; in other words enhancements
  3. I have no opinion about MediaWiki messages
  4. somewhat tricky hard to understand [template] code ... should I then choose template code...? Hell no. You don't endear yourself to other coders by writing code that is hard to understand; those who will come behind you to maintain your tricky code will curse the day you were born – coders who think that tricky hard to understand code is CRUISE CONTROL FOR COOL should be taken out back and thumped. I have helped editors at a variety of the MediaWiki wikis with their implementations of the Module:Citation/CS1 suite of modules; most of those have been smaller; I have seen that same module suite on non-MediaWiki wikis so, as a guess, any wiki manager who wants lua in their installation can get it
  5. try lua, you might find that you like it
—Trappist the monk (talk) 02:35, 1 January 2020 (UTC)[reply]
  1. Yes, Lua modules do run faster, but you shouldn't care unless there is some indication of a performance problem.
  2. I wouldn't know; I've been going around TfDing that kind of lua module as "Unnecessary Lua module, can be implemented in Wikitext"
  3. There's no specific preference for MediaWiki messages; I consider that usage perfectly fine given that Module:IPAddress already existed. You should, however, delete Template:IP-user other/core now that it is no longer in use
  4. This is a matter of some controversy; I may TfD the module if I can eek out the template code version myself, however in practice those TfDs have had inconsistent results.
  5. I know of no statistics on that matter
One final comment: If you do create a new Lua module, please don't forget to document it, give it the same name as the template that calls it, tag the template with {{lua}}, and redirect the module's talk page. I've been having to complete one or more of these steps for a wide variety of different modules. * Pppery * it has begun... 02:43, 1 January 2020 (UTC)[reply]
Thanks you all. I feel more updated now. So my interpretation is as follows: Template code is still fully accepted to use. And we can use template code, or Lua, or both combined, whatever we prefer and whatever works and gets the job done. And of course, as an old software engineer I do see the benefits of having a proper programming language like Lua, just that at the moment it would be inadvisable for me to learn another programming language. I lost count of the number of languages I have learnt and forgot since I started coding back in 1982. I am usually only able to work with and efficiently use two or three languages during the same year, my head can't handle more at the same time.
Trappist the monk: No worries, I don't write tricky and hard to understand code to impress. But I prefer to solve the problems as well as possible, and that sometimes leads to rather complex code to handle all the stuff the best way. So yes, some of my templates have kind of "scary" code. But I usually add lots of code comments and documentation to make it easier on the next programmer.
Trappist the monk and Pppery: Haha, it was funny that you kind of threw my old documentation advice back at me. I was one of the people that helped build and design the green template documentation boxes we use here. And I was one of the early adopters of the method to redirect all the talk pages of a template and its subpages to the same talk page. (But I didn't come up with the idea.) It confused people at first, so we started adding a brown box at the top explaining it was a joint talk page.
And regarding performance. We have had performance problems with templates. Back in 2007 and 2008 it was so bad that at times the Wikipedia servers totally stopped serving images, and just showed the text of the articles. And it was normal that it took hours or days for categories to be updated. But that also shows that MediaWiki is well built, it has the right priorities: If overloaded, it still keeps serving the most important part. Some of the culprits were the string handling templates, we had to optimise them a lot to not overload the system. The Wikimedia system admins threatened to turn off the parser functions / magic words we used in those templates. Although the main reason the servers got overloaded was that many admins were doing rapid experimental edits (about one edit a minute) on protected templates deployed on a million pages. That's why we added those warning boxes "This template is used on a million pages" and added the /sandbox and /testcases links on the green template documentation boxes.
--David Göthberg (talk) 05:35, 1 January 2020 (UTC)[reply]
Davidgothberg, good times right ?? :) Awesome to see u here again David. —TheDJ (talk • contribs) 14:40, 1 January 2020 (UTC)[reply]
I'll add to the above to say that as the complexity of a template (or whatever functionality it implements, which ideally the template complexity should be tied to but unfortunately isn't always so) increases, the argument for converting it to Lua strengthens, even if that template isn't doing any specific, individual task that Lua would be better suited for. Of course, at what point a Lua conversion becomes more preferable than a wikitext template, is up for debate, and different people who value different aspects of template/Lua design and view the issue from different perspectives, could easily have different, well-reasoned thresholds. But to pick a couple egregious cases, I don't think there's anyone here who would seriously argue for a return to the wikitext versions of {{navbox}} or the cite templates, for example. =) 「ディノ奴千？！」☎ Dinoguy1000 18:16, 1 January 2020 (UTC)[reply]
Both of those are bad examples because they perform the lua-exclusive task of supporting an infinite number of arguments. However, if phab:T203293 or phab:T114432 were fixed, I would seriously consider a Wikitext rewrite of Template:Navbox, using Lua only for the specific places in which an infinite number of parameters are needed. * Pppery * it has begun... 18:41, 1 January 2020 (UTC)[reply]
TheDJ: Ah yes. And nice to see yet another familiar name around here.
Dinoguy1000: I expected this discussion to quickly become philosophic. :)
And the {{navbox}}: There seems to be many ways to implement that "monster". I myself tried my hands at it when it was a bit new. I managed to make a working one that was <div> based instead of <table> based. (Back then it was the latest craze to make everything <div> based.) But upon comparing my version with the table based one, I came to the conclusion that the table approach is better. (Table approach is more manageable with less messy code.) Thankfully I am the kind of person that prefer the best solution before my solution, so I was happy to let my version go. Besides, I really didn't want to become a caretaker of {{navbox}}.
--David Göthberg (talk) 03:47, 2 January 2020 (UTC)[reply]

block expiration time 50 year ago

At Category:Requests for unblock under summary section, you can see many editors who were supposed to be unblocked 50 years ago. Any guess whats causing this? My guess is lazy admins since last 51 years. —usernamekiran(talk) 10:20, 1 January 2020 (UTC)[reply]

Unix time started 1 January 1970, 50 years ago. It must be something to do with that.   Jts1882 | talk  11:19, 1 January 2020 (UTC)[reply]
Yes. It transcludes User:Cyberbot I/Requests for unblock report which says {{Time ago|19700101000000}} for indefinite blocks. It started failing 26 September 2019.[3] It was reported to Cyberpower678 at User talk:Cyberpower678/Archive 67#User:Cyberbot I on Category:Requests for unblock, Summary section. PrimeHunter (talk) 12:53, 1 January 2020 (UTC)[reply]

Change in searchable contributions

Recently a change has been made to how someone can view a person's contributions. If you want to view a person's last 20 contribs, the link looks like this:

  • https://en.wikipedia.org/w/index.php?title=Special:Contributions/Hammersoft&offset=&limit=20&target=Hammersoft (note the bolded text)

If it's the last 50, it's "limit=50", and so forth. It used to be the case that you could change that URL so to "limit=5000". I used this on occasion when deep searching for particular contributions based on article name or edit summary. This has now been changed, and limits any request over 500 to 500. This is not the case for article histories, where you can still do up to 5000.

Why was this changed, when was it changed, and did the community have any say in its being changed? If so, where? Thanks, --Hammersoft (talk) 15:42, 1 January 2020 (UTC)[reply]

The phabricator task about this is phab:T234450. Stryn (talk) 15:49, 1 January 2020 (UTC)[reply]
@Hammersoft: This is Wikipedia:Village pump (technical)/Archive 177#Changes to Special:Contributions. --Redrose64 🌹 (talk) 21:53, 1 January 2020 (UTC)[reply]

Magic link

It appears that the template at Wikipedia:Village pump (proposals)#RFC on decorative quotes unexpectedly leads to an external website rather than to the Wikipedia RFC. I'm not sure if this is somehow related to the removal of the old magic links, or if someone needs to look at the template code, but it seems like folks probably want to end up at WT:MOS than at the IETF's website. Whatamidoing (WMF) (talk) 06:22, 2 January 2020 (UTC)[reply]

That's interesting: [[rfc:hello]] → rfc:hello which links to ietf.org. The reason for that is the "RFC" entry at meta:Interwiki map. Johnuniq (talk) 06:53, 2 January 2020 (UTC)[reply]
The wrong link was made manually.[4] PrimeHunter (talk) 12:22, 2 January 2020 (UTC)[reply]
(edit conflict) I don't see any template involved there. The wikitext is {{FYI|pointer=y|New RfC at [[RfC: Use of Decorative Quotes in article space, and the Cquote template]]}}; the link is in the wikitext, not being generated by the template. As noted above, "rfc" is in the interwiki map as a link to IETF RFCs. And even if it weren't, that link would be trying to go to a mainspace page instead of the intended section of Wikipedia talk:Manual of Style. Anomie⚔ 12:30, 2 January 2020 (UTC)[reply]

Recent changes isn't loading

I try to click on the 'Recent changes' tab, but I am unable to. It does not load. I understand that this has been brought up before and fixed. Thanks, Thatoneweirdwikier Say hi 08:06, 2 January 2020 (UTC)[reply]

Are you talking about clicking Special:RecentChanges in the sidebar? It works for me. Johnuniq (talk) 09:51, 2 January 2020 (UTC)[reply]
Johnuniq, yes. I've also tried entering the URL manually. There are other tabs that do work though. Thanks, Thatoneweirdwikier Say hi 10:37, 2 January 2020 (UTC)[reply]

Thatoneweirdwikier: It might help if you share what browser and skin you're using, as well as the exact URL you are trying to access. It would also help if you could be more specific about "isn't loading". Is the page completely blank? Does it say "No changes during the given period match these criteria."? Do you see a spinner? It would also be good if you can open your browser console (should be f12 in most browsers) and paste the warnings (yellow) and errors (red) here. Nirmos (talk) 11:56, 2 January 2020 (UTC)[reply]

Nirmos, I use Safari on the latest version of MacOS (Catalina, 10.15.2). The URL I'm trying to access is here. The screen does not go blank; rather, it freezes on the current page I am on. No spinner either. I've pasted the 1 error and 3 warnings I was presented with below. I can't seem to find a skin, unfortunately.
Failed to set referrer policy: The value 'origin-when-crossorigin' is not one of 'no-referrer', 'no-referrer-when-downgrade', 'same-origin', 'origin', 'strict-origin', 'origin-when-cross-origin', 'strict-origin-when-cross-origin' or 'unsafe-url'.
load.php:144:175
This page is using the deprecated ResourceLoader module "jquery.tipsy".
load.php:155:710
This page is using the deprecated ResourceLoader module "jquery.ui".
Please use OOUI instead.
migrateWarn — load.php:144:751
JQMIGRATE: jQuery.fn.delegate() is deprecated
Hope this helps. Thanks, Thatoneweirdwikier Say hi 12:52, 2 January 2020 (UTC)[reply]
Does the page work when you are logged out? Galobtter (pingó mió) 12:54, 2 January 2020 (UTC)[reply]
@Thatoneweirdwikier: Can you see if it works when you load it in safemode? — xaosflux Talk 13:40, 2 January 2020 (UTC)[reply]

So, while investigating this (by enabling gadgets) I did find two errors. First there's TypeError: frame.contentDocument is null from MediaWiki:Gadget-mobile-sidebar.js. Then there's TypeError: AFCH.Submission is undefined. This is from MediaWiki:Gadget-afchelper.js which loads User:Enterprisey/afch-master.js which loads User:Enterprisey/afch-master.js/core.js which loads User:Enterprisey/afch-master.js/submissions.js. Neither of those errors actually seem to cause this issue, but they should probably be fixed anyway. Maybe the actual issue here is phab:T238442. Nirmos (talk) 14:18, 2 January 2020 (UTC)[reply]

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