Wikipedia:Village pump (technical)

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

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.

Frequently asked questions (FAQ) (see also: Wikipedia:FAQ/Technical)
Click "[show]" next to each point to see more details.
If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See bug 1864. There is an accesskey property on it (default to accesskey="f" in English), and for logged in users there is a gadget available in your preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you have problems making your fancy signature work, check Wikipedia:How to fix your signature.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
For server or network status, please see Wikimedia Metrics.
« Archives, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175


Not running "Community tech bot" for Popular pages[edit]

Bumping thread for 30 days. JoeHebda (talk) 02:46, 19 July 2019 (UTC) Greetings, Community tech bot appears to be down (not running) since April, 2019. Instructions are To report bugs, please write on the Community tech bot talk page on Meta. I did report in June, and with no response. Wondering if an expert here could fix? For example, Wikipedia:WikiProject Saints/Popular pages Updated: 6:32 pm, 26 April 2019, Friday (2 months, 13 days ago). Regards, JoeHebda (talk) 13:06, 8 July 2019 (UTC)

  • @MusikAnimal (WMF): any insight in to this? — xaosflux Talk 18:59, 8 July 2019 (UTC)
    The cron job for this month didn't start for some reason. I have manually triggered it. "Saints" is pretty far down the list so it may be a while before the bot gets to it. I don't have an answer as to why no report was created for May and June, but I will investigate. Also, don't forget about toolforge:massviews which can give you the same information in real-time: [1]. That tool seems to be having problems of its own (lots of errors querying the pageviews API, tracked at phab:T219857), which I'm starting to believe might be the same reason Popular Pages bot isn't finishing some reports. MusikAnimal (WMF) (talk) 20:12, 8 July 2019 (UTC)
    Thanks @MusikAnimal (WMF): - I really like viewing Popular Pages on my fav. WPs; very helpful! Wondering if bot stalls out if it's not done running current month jobs & at calendar new month (day 1) starts a second bot? Just curious... JoeHebda (talk) 12:26, 9 July 2019 (UTC)
    I suspect all the reports will be done within the next two weeks. If not, the reports for July will start populating on the 3rd. This is because it takes up to two full days for the previous month's data to be available. Best, MusikAnimal (WMF) (talk) 17:28, 9 July 2019 (UTC)
    Hello @MusikAnimal (WMF): - Since starting at 15:41, 8 July 2019, the bot as of this morning has processed 60 WPs out of over 1,600 so it has a long ways to go to complete. At 30 perday, thats 53 days of runtime. JoeHebda (talk) 14:01, 10 July 2019 (UTC)
    The bot only goes through WPs configured at User:Community Tech bot/Popular pages config.json, which is about 800 or so. Most of these are quite small and will be processed quickly. That said I certainly can't guarantee they will all be finished before the month is over. We are monitoring and are discussing ways to improve performance. Thanks for your patience, MusikAnimal (WMF) (talk) 18:39, 10 July 2019 (UTC)


  1. Should the Lists table be updated? So it matches the Config table.
  2. Should the Config page include instructions to (manually) maintain the Lists table?
  3. Any way to have Techbot update that Lists table?
  4. Should Lists page be abandoned/redirected to config page? Pageviews on List page are about 25 per day.


These questions are beyond any decision that I can make on my own. Asking for more people to chime in with discussion. JoeHebda (talk) 20:22, 10 July 2019 (UTC)

I had no idea about WP:POPT. I don't think it worth the trouble to update that table. The list appears to be manually categorized. The only other information it has over User:Community Tech bot/Popular pages is the shortcuts, which aren't that important in my opinion. So yes, simply redirecting the list page seems sensible. MusikAnimal (WMF) (talk) 20:53, 10 July 2019 (UTC)
  •  Working - Update table? or Redirect page? JoeHebda (talk) 02:50, 19 July 2019 (UTC)


Greetings User:MusikAnimal (WMF) - Wonder if adding Pageviews to Popular pages would better show each WPs "Popular pages" activity? As an example, I added at Wikipedia:WikiProject Chemistry/Popular pages. Just spot-checking I've not found any WP with much activity. Maybe because of the bot not running since end of April? JoeHebda (talk) 03:34, 11 July 2019 (UTC)

If you mean no one is checking these reports, you're mostly right. A few months ago I did some spring cleaning and removed a bunch of apparently inactive WikiProjects from the config. There are probably more that we could remove. MusikAnimal (WMF) (talk) 23:56, 11 July 2019 (UTC)
  •  Working - Add Pageviews to Bot-generated popular pages? Wait until July process is done. JoeHebda (talk) 02:53, 19 July 2019 (UTC)

Bot posting to WP talk pages[edit]

Hi User:MusikAnimal (WMF) - When the bot updates User:Community Tech bot/Popular pages, could it also post a notice at the WikiProject's talk page? This would increase awareness of Popular pages & perhaps encourage usage. Regards, JoeHebda (talk) 03:40, 11 July 2019 (UTC)

We certainly can, though I'd like to hear input from more people. Many WP talk pages get a lot of spam, and some already have the popular pages report transcluded on the main WP page. MusikAnimal (WMF) (talk) 23:58, 11 July 2019 (UTC)


Question: Post a time-stamped completion message from Community Tech bot, onto each Wikiproject's Talk page? JoeHebda (talk) 02:57, 19 July 2019 (UTC)

Bot issue with WP Paintball[edit]

  • Good morning User:MusikAnimal (WMF) - Looking at logs for "Community Tech bot" starting at 01:14, 11 July 2019 and continuing until 02:01, 11 July 2019, the bot processed for Wikipedia:WikiProject Paintball/Popular pages eleven times. Wondering why?
  • Also noticed that since Revision as of 01:33, 11 July 2019 the bot at User:Community Tech bot/Popular pages has stopped updating WPs?
  • Sorry for these questions - similar to problems when I was involved with "WP 1.0 bot" for article assessment tables. Mostly caused by WPs not setup correctly, or Talk page coding errors causing the bot to respond incorrectly. Regards, JoeHebda (talk) 14:03, 11 July 2019 (UTC)
    These were test edits. I chose that report because apparently no one reads it. MusikAnimal (WMF) (talk) 23:53, 11 July 2019 (UTC)
    Normally the bot only updates that page after it's finished going through all WPs. I've been manually updating it (via script), just to keep track of where we are. I'm going to make the bot update it regularly on its own. MusikAnimal (WMF) (talk) 23:53, 11 July 2019 (UTC)
    No worries :) MusikAnimal (WMF) (talk) 23:53, 11 July 2019 (UTC)

Is the bot running - July 14th[edit]

  • Hi User:MusikAnimal (WMF) - checking the bot, it has not posted any updates for "Popular pages" WPs since 12:08, 13 July 2019. Has it been paused, or just stopped on it's own because of an error? Regards, JoeHebda (talk) 10:19, 14 July 2019 (UTC)
    It went down over the weekend, apparently. It's back up and running now. Rest assured I'm monitoring and we'll have all reports finished in the next week or so. There's a new, much faster version of the bot that I'm almost done with, so hopefully next month we won't see any problems. Best, MusikAnimal (WMF) (talk) 16:58, 15 July 2019 (UTC)
    Thanks User:MusikAnimal (WMF) for the update. Wondering if the number of popular pages for an individual wikiproject makes much of a difference? For example, would the bot process any faster if the WP asked for only top 100 vs. to 1,000? JoeHebda (talk) 17:41, 15 July 2019 (UTC)
    Unfortunately no. It's the size of the WikiProject itself that matters; the bot must go through every mainspace page, along with all of their redirects. MusikAnimal (WMF) (talk) 23:14, 15 July 2019 (UTC)

Version 0.7 Popular pages question[edit]

  • Hi User:MusikAnimal (WMF) - This morning I noticed Wikipedia:Version 0.7/Popular pages ran at 06:15, 17 July 2019 for about 5 minutes. After some investigation, I'm wondering if this "WP" can be made Inactive? Pageviews are very low. In the grand scheme of things, that runtime might not be much. JoeHebda (talk) 13:19, 17 July 2019 (UTC)
    It is about 31,000 articles, which isn't very many. It's up to the community if they want to remove it from the bot config. I've mostly only been removing WPs that are explicitly marked as inactive or defunct. MusikAnimal (WMF) (talk) 14:38, 17 July 2019 (UTC)

Bot completion errors?[edit]

  • Hi User:MusikAnimal (WMF) - Community Tech bot "Update report" posted over 10 times without updating any WPs in the table. From 18:01, 18 July 2019 to 21:31, 18 July 2019.
  • There are several WikiProjects that were missed (according to the table)
    • WikiProject Eastern Orthodox Church/Popular pages - 2019-03-15
    • WikiProject Software/Free Software/Popular pages - 2019-03-15
    • WikiProject Las Vegas/Popular pages - 2019-04-08
    • WikiProject Water supply and sanitation by country/Popular pages - 2019-04-26

Regards, JoeHebda (talk) 03:12, 19 July 2019 (UTC)

Thanks for alerting us! Eastern Orthodox Church was broken because of a recent rename. I've inquired about this on the talk page. Free Software has been updated. The other two WikiProjects are now inactive, so I've removed them from the config. Best, MusikAnimal (WMF) (talk) 22:08, 22 July 2019 (UTC)

Thumbnail image doesn't show in List of tallest structures in Tokyo[edit]

The thumbnail of No. 28 (Shin-Marunouchi Building) in list 1 doesn't show up here. it has been like this for days. I tried to purge the page, didn't help.

Any clue? Thanks.--fireattack (talk) 22:49, 29 July 2019 (UTC)

It works for me. Try to bypass your own cache. PrimeHunter (talk) 01:13, 30 July 2019 (UTC)
I think the reason is that particular thumbnail returns the header says "content-type: application/x-www-form-urlencoded" instead of common "image/jpeg".
Can you try to open directly and see what happens? Here, it will try to download itself instead of just display. I can see this weird behavior in both Firefox and Chrome and it doesn't happen to other images.
But in Firefox, it can still display the image this way in <img> tag (but not in Chrome). --fireattack (talk) 10:17, 30 July 2019 (UTC)

Not just this list, some other thumbnail images don't load well at List of Cheers characters, List of Friends characters, and List of The Big Bang Theory and Young Sheldon characters. Check other list pages. George Ho (talk) 00:13, 6 August 2019 (UTC)

Update: The root cause is Phab:T188831. And about why it starts to cause more apparent issue, see .--fireattack (talk) 20:42, 6 August 2019 (UTC)

Saw the issue at List of highest-grossing films as well with the first image. Hopefully it will be resolved before long. Master of Time (talk) 05:43, 14 August 2019 (UTC)

Enable chess PGN viewer for chess articles[edit]

Should the interactive portable game notation viewer in use on the Hebrew, Russian, and Ukrainian Wikipedias be enabled on the English Wikipedia? 05:28, 30 July 2019 (UTC)


Chess games can be described in a standard machine-readable format, portable game notation, so that these games can be displayed on computers. On a number of websites the user interface allows for PGN to be rendered as an interactive board so that readers can browse through games. Around 2013, User:קיפודנחש developed a JavaScript application that brings this functionality to Wikipedia articles about chess which has been in use on the Hebrew Wikipedia. You can see examples of this at the Hebrew Wikipedia articles for The Immortal Game (en) and The Evergreen Game (en). A number of discussions have occured at VPT on interactive chessboards (you can find them by searching "PGN viewer" in the archives) with the most recent being Wikipedia:Village pump (proposals)/Archive 132#Interactive chess boards in 2016. That discussion was closed by User:Cunard as having "a clear consensus to support the general proposal of enabling interactive chess boards on the English Wikipedia." While people were generally in favor of the functionality, the technical implementation was never fully discussed.


The code at he:Mediawiki:Gadget-pgnviewer.js and he:Mediawiki:Gadget-pgnviewer.css will be copied to MediaWiki:Gadget-pgnviewer.js and MediaWiki:Gadget-pgnviewer.css. A template (perhaps {{PGN viewer}} or {{Chess game}}) will be created that takes the PGN and other parameters and outputs a <div> with the class '.pgn-source-wrapper'. MediaWiki:common.js will be modified to add the following code which only loads the PGN viewer gadget when viewing a page that has the template:

$( function() {
    if ( $('.pgn-source-wrapper').length > 0) {
        mw.loader.load( 'ext.gadget.pgnviewer' ); //"manually" load the hidden gadget
} );

(For more details and alternative implementation possibilities, see Kipod's description in #"on demand" loading of scripts and gadgets)

PGN viewer discussion[edit]

  • Support as proposer. This has been around a while and seems stable enough for use on hewiki. Use on an additional Wikipedia will also help development, as previous proposals seem to have led to good feedback that קיפודנחש has taken into account to improve it on hewiki. Having a PGN viewer would greatly improve our chess coverage as readers can use the viewer to follow along with the game as the article describes it without having to know algebraic notation (chess) or have their own chess board or program. Some comments from around 2013 suggested it be turned into a gadget, but those efforts have been stalled since 2013. Plus, making it a gadget only allows logged in readers to use the PGN viewer despite it being broadly useful for reading rather than editing. Wug·a·po·des​ 05:28, 30 July 2019 (UTC)
  • This definitely should not be in common.js - rather the proposal should be for addition as a default gadget (for reasons as mentioned in the comment at the top of MediaWiki:Common.js), which can be used by any user whether logged-in or logged-out. Galobtter (pingó mió) 06:00, 30 July 2019 (UTC)

So this is in use now in hewiki, ruwiki, and ukwiki (the latter has the script and template, but it's used only in few articles). All 3 are using "on demand" loading. The script itsslf weighs 27k (20 minimized), and loading it unconditionally is undesired, as only small fraction of sll articles are chess related. The mechanism on hewiki is to create a "hidden", non-default gadget, and have common.js look for a "marker" class in page, triggering loading the gadget. (i will try to add some information WRT "on-demand", or "template-controlled" loading of scripts on ruwiki and hewiki later). peace - קיפודנחש (aka kipod) (talk) 13:29, 30 July 2019 (UTC)

@Wugapodes: i read this thread on mobile, and missed an important detail: the script on hewiki _is not_ w:he:מדיה_ויקי:Common.js/pgn.js. this one is an outdated version that should not be used. the script is in he:Mediawiki:Gadget-pgnviewer.js and its CSS, he:Mediawiki:Gadget-pgnviewer.css. this is important: User:Krinkels made some instructive comments in Wikipedia talk:WikiProject Chess/Interactive chess boards, and the correct version addresses many (most?) of the points he raised. peace - קיפודנחש (aka kipod) (talk) 14:50, 30 July 2019 (UTC)

  • yes. Please implement it. I want to study it so that I can convert it into a shogi version (although i'll probably need help for getting the dropped pieces part). – ishwar  (speak) 17:33, 30 July 2019 (UTC)
    @Ish ishwar: you really don't need it "implemented" on enwiki in order to study it. the script is available in the link above - please read the "license" notice at the top: it is more permissive than cc-by-sa. basically, it says "you can do whatever you want with this". however, the main piece there is the "pgn analyzer". i am not aware of PGN standard for shogi. i saw "PSN" mentioned, but could not find good reference explaining it. if it's similar enough to PGN, it might not be that difficult. peace - קיפודנחש (aka kipod) (talk) 19:25, 30 July 2019 (UTC)
    i see. Thank you. There is a PSN format. However, no one really uses it. (It was created by Europoean folks after all.) Probably the best is the CSA format. It looks like this:
Shogi notation example
P2 * -HI *  *  *  *  * -KA * 
P4 *  *  *  *  *  *  *  *  * 
P5 *  *  *  *  *  *  *  *  * 
P6 *  *  *  *  *  *  *  *  * 
P8 * +KA *  *  *  *  * +HI * 
  • Support for all the same reasons I supported several of these past proposals, which have been generally uncontroversial but stopped short of implementation. — Rhododendrites talk \\ 18:42, 30 July 2019 (UTC)
  • Oppose for anything on by default unless and until this is supported by an extension, which can actually deliver the Javascript as needed. As for opt-in, sure, but it should not require any change to the wikitext as that would not be supported for most people. --Izno (talk) 21:51, 31 July 2019 (UTC)
  • Support it just looks and works wonderfully on the Hebrew Wikipedia. I don't know about any technical issues, but I'd even recommend just copying the Hebrew version (if that would work similarly to what works there) and make any needed technical changes as people can agree on them. Smallbones(smalltalk) 13:33, 1 August 2019 (UTC)
  • I agree that using a template to trigger page-specific loading of scripts and gadgets is a reasonable way to implement on-demand loading of Javascript. As I prefer generic solutions to one-off solutions, I support introducing this mechanism and approving Kipod's PGN viewer gadget for on-demand loading. (This does not preclude anyone in future deciding to implement another PGN viewer gadget.) isaacl (talk) 17:52, 1 August 2019 (UTC)
  • Yes – an obvious improvement, nice interface, will be useful to readers. Levivich 06:10, 2 August 2019 (UTC)
  • Strong support: the lack of an interactive interface like this is the reason I'm often frustrated by Wikipedia chess articles and often visit other sites to find the information I'm looking for. We should have been using this PGN viewer years ago. — Bilorv (// W A K E U P //) 06:59, 2 August 2019 (UTC)
  • Support I'd like to be able to "play . a . game" — Ched :  ?  — 00:03, 4 August 2019 (UTC)
  • Support Nice addition to our chess-related articles. Pichpich (talk) 20:34, 4 August 2019 (UTC)
  • Strong Support -- I know very little about the technical aspects of Wikipedia, but since it appears to be stable on another language of this encyclopedia of ours, I fully support implementing it. -- Dolotta (talk) 22:39, 7 August 2019 (UTC)
  • Sounds good, seems harmless enough. Support. Stifle (talk) 09:51, 8 August 2019 (UTC)
  • What a neat feature to have. I love the way it's implemented in the he-wiki article. Support. 28bytes (talk) 04:53, 9 August 2019 (UTC)
  • Support as an on-demand gadget which would load automatically on relevant pages. Great work, and very informative when studying a game. — JFG talk 10:27, 12 August 2019 (UTC)
  • Support as per Dolotta. I can think of a few articles where this could be useful. --LukeSurl t c 13:48, 13 August 2019 (UTC)
  • Support.--Vulphere 15:54, 13 August 2019 (UTC)
  • Support seems like a good feature and a reasonable technical implementation. power~enwiki (π, ν) 17:46, 14 August 2019 (UTC)
  • Support: Interactive elements in websites aren't the future. They aren't the present. They were years ago. Esquivalience (talk) 04:59, 16 August 2019 (UTC)

"on demand" loading of scripts and gadgets[edit]

I'd like to describe the "on demand loading" mechanism used on ruwiki, hewiki, and others (e.g., runews, ukwiki and more).

So, most of our site-specific code has to do with utilities meant mainly for editors, but there are some scripts which affect the content, for reading. An example on enwiki is the part in mediawiki:common.js that deals with collapsing, and the part that executes special code when reading the main page.

In many cases, this special code is only relevant on minority of the content pages: for instance, most pages on enwiki do not need the special code that deals with "collapse" css classes. In this case, the code itself is short, so loading it whether it's needed or not makes little difference. However, some other projects want to load longer scripts affecting the content for reading. The pgn viewer discussed above is one such example. The wikipedians on ruwiki created a simple mechanism to support this, and i'd like to describe it here.

  • In this context, "on demand" means "template-controlled": so a template can "instruct" the system to load a script which is not normally loaded, when the template contains some element that needs this extra juice.
  • The system can't load "any arbitrary script". It can trigger loading one of well-defined set of scripts, and this set is vetted with the same level of caution used for vetting whatever goes into common.js
  • The system uses a small code snippet in common.js, and a special template for triggering the "on-demand" switch. The code on ruwiki is the 11 lines, beginning at line #325 in ru:Mediawiki:Common.js, and the template is in ru:Template:Выполнить скрипт. i will call it {{Load script}}.
  • The machinery is super simple: the "Load script" template creates a hidden element, with a specific class ("ExecuteJS"), and a data attribute that contains the name of the requested script. The common.js code scans the page for elements with this class, and if found, it extracts the script name from the data attribute, and then loads Mediawiki:Script/<scriptname>.js. The sysops make sure only sanctioned scripts will get to be in "Mediawiki/Script/", with the same level of scrutiny they use for Common.js
  • A template that desire to load a script which, e.g., adds some special behavior to "imagemap", will include something like {{ Load script | imagemap-enhancer }}. When a page transcludes this template, the script Mediawiki:Script/imagemap-enhancer.js will be loaded. This way, ruwiki can "enhance" imagemaps, without adding bloat to any page that _does not_ transclude this template (i.e., all but a handful of pages).
  • In hewiki, we tweaked this system a little bit (line #261-275 in he:Mediawiki:Common.js) , to allow loading of gadgets, as well as scripts (the gadget name must begin with "ondemand", so this can't be used to sneakily load any "normal" gadget that the reader did not enable - only one of very few sanctioned "ondemand" gadgets)

I hope this description is good enough for User:Izno to overcome their opposition. I wanted to present this mechanism to the technical community on enwiki, but it's not absolutely essential: it's possible to avoid the bloat by taking the following steps:

one-off alternative to generic "on-demand" loading
  • Create a "hidden" gadget with the script (hidden gadgets can't be selected by users, and unless you mark them "default", they never load)
  • Have a small snippet in common.js that looks approximately like so:
    $( function() {
        if ( $('.pgn-source-wrapper').length > 0) {
            mw.loader.load( 'ext.gadget.pgnviewer' ); //"manually" load the hidden gadget
    } );

This will achieve the same objective: The script will load if and only if it should load, so if enwiki will have, say, 578 articles which want to show interactive chess game, the script will load for readers only when they view one of those pages, and the other 4M+ articles will not have to pay the bloat. peace - קיפודנחש (aka kipod) (talk) 23:41, 31 July 2019 (UTC)

I've updated the implementation section with your one-off suggestion since it seems simplest. Wug·a·po·des​ 03:14, 1 August 2019 (UTC)
One-off alternative looks good, but on enwiki rather than having that sort of small snippet in common.js, it is done in the form of a default gadget (e.g MediaWiki:Gadget-geonotice.js) that loads that "core" hidden gadget (e.g. MediaWiki:Gadget-geonotice-core.js), which also allows people to disable the gadget if they don't like it. I would agree with Izno that it would be nice if things like these were implemented as an extension rather than as a gadget, but making something to an extension would certainly delay this considerably and possibly make it so no solution is ever implemented. Galobtter (pingó mió) 06:43, 2 August 2019 (UTC)

Suppress rendering of Template:Wikipedia books[edit]

As many are aware Wikipedia books has not worked in a few years and there's no light down the tunnel of any fixes coming...Reading/Web/PDF Functionality (no update on WikiBooks in a year). I am proposing suppressing the rendering capability of Template:Wikipedia books ( related =Template:Book bar & Template:Books-inline) and removal of the Book Creator in the sidebar. This is for our readers so they don't keep going to books that don't work and haven't worked in a few these types of lists exist in outlines already. I'm thinking suppression of the template(s) is better than outright deletion in case the WMF finally does come up with something...then poof...they can all appear when transclusion is implemented again. Currently PDF rendering per page has been implemented so the link seen at Wikipedia:Books about an external program is no longer needed as our in-house PDF system is running.--Moxy 🍁 22:57, 6 August 2019 (UTC)

Discussion (Wikipedia books)[edit]

  • Good idea and a future-proof solution. Support per nom. Wug·a·po·des​ 01:20, 7 August 2019 (UTC)
  • I think this is a good idea. Headbomb did some work with this stuff years ago and he might also have some comments about it. Killiondude (talk) 06:08, 7 August 2019 (UTC)
  • Support. Ruslik_Zero 08:42, 7 August 2019 (UTC)
  • Support, I didn't even know it's not working. Stryn (talk) 10:37, 7 August 2019 (UTC)
  • Seems like phab:T224922 may be relevant here, as mw:Extension:Collection is the extension behind "books". Anomie 12:10, 7 August 2019 (UTC)
  • Support per nom. Masum Reza📞 14:22, 7 August 2019 (UTC)
  • Book namespace entirely is dead. There'd be no harm in scrapping it completely. – Ammarpad (talk) 16:24, 7 August 2019 (UTC)
  • Comment if outlines are more up to date and maintained and are basically redundant, get rid of books. But wait.... these things are for readers, right? Are readers more likely to look for "books" or "outlines"? Maybe we should migrate the excellent and maintained content from outline to "books" and then get rid of outlines. We still reduce fluff but combine maintenence with readership. NewsAndEventsGuy (talk) 17:58, 7 August 2019 (UTC)
  • If it's dead, it's dead. Can be suppressed until and if things come back online. Headbomb {t · c · p · b} 18:04, 7 August 2019 (UTC)
  • Support. Hrodvarsson (talk) 04:52, 9 August 2019 (UTC)
  • Support per nom. SD0001 (talk) 20:11, 14 August 2019 (UTC)
  • Support No point offering something to users that can't be used.Nick Moyes (talk) 12:10, 16 August 2019 (UTC)

Why do my searches come up empty?[edit]

If I search for say 'Airport' in the above, I'm taking to an empty result page. I'd expect it to find Wikipedia:WikiProject Airports/Article alerts, giving it's in Category:All Wikipedia article alert reports. Headbomb {t · c · p · b} 13:30, 11 August 2019 (UTC)

For category search to work correctly, the category has to actually be in the source text. Wikipedia:WikiProject Airports/Article alerts is only in Category:All Wikipedia article alert reports via a template transclusion. So for the search extension, the page does not have that category since it's not in its wikitext. – Ammarpad (talk) 14:00, 11 August 2019 (UTC)
That is... rather silly. I'll find another way then. Headbomb {t · c · p · b} 14:36, 11 August 2019 (UTC)
Actually now it shows up. Probably a caching issue then. Headbomb {t · c · p · b} 14:37, 11 August 2019 (UTC)
True. I see that. I believe it must have been enhanced at sometime, it previously didn't work with transclusion. – Ammarpad (talk) 08:27, 12 August 2019 (UTC)

Blocked spammer posts link[edit]

Many or most of the blocks I perform are for spam-only accounts, especially those whose only edits are placing spam on their userpage. Just in case someone wants to apologise and become productive, I leave the talk page open when I do a {{uw-spamblock}}, unless the talk page itself has been used for spamming. On one hand, I don't want to shut down access without evidence of abuse, but on the other hand, it's possible that the talk page would be used abusively. My interest, therefore, is finding an automated way (i.e. without human edits or bot edits) to detect a post-block addition of an external link, the results of which could be evaluated as spam or not-spam by a human. I'm envisioning the following criteria:

  • User has been indefinitely blocked for spamming — detect because user is indefinitely blocked, and either rationale or talk page has {{uw-spamblock}} or some other "you have been blocked for spamming" template
  • After block is performed, user edits talk page and adds an external link
  • If user has added {{unblock}}, the external link is not inside the unblock template

Obviously this kind of thing happens sometimes, but I have no clue how often; in case it's a rare event, I don't want to request an edit filter and tie up system resources. Is there any other way to detect this (either conclusively or "this is likely"), perhaps a database report of users that are indefinitely blocked and that have external links on their talk pages? Nyttend (talk) 04:48, 12 August 2019 (UTC)

Here's a Quarry query that might serve as a database report: quarry:query/38333. Anomie 12:59, 12 August 2019 (UTC)
Hi, Anomie, and thank you. One question — can you embed links in the report, and if you can, would you link the talk pages in question? It would be a lot faster to look at these pages if I could just click a link. Nyttend (talk) 02:12, 13 August 2019 (UTC)
There does not appear to be a way to directly embed links in the quarry output. Anomie 11:57, 13 August 2019 (UTC)

"Move subpages of talk page (up to 100)" checkbox unticked by default[edit]


I'm pretty confident I've seen a thread on this topic, and we made sure the default was to then keep it checked, for reasons of not making stupid mistakes. Was the change reversed or am I seeing things? --qedk (tc) 05:24, 12 August 2019 (UTC)

QEDK, the change hasn't been merged - see phab:T222953. You can put this snippet (written by someone else) in your Special:MyPage/common.js:
:/* Automatically tick the "Move subpages" option when moving pages.*/
:var moveSubpagesBox = document.getElementsByName("wpMovesubpages")[0];
:if (moveSubpagesBox !== undefined) {
:  moveSubpagesBox.checked = true;
to automatically tick it though. Galobtter (pingó mió) 06:13, 12 August 2019 (UTC)
Thanks, @Galobtter:, not quite sure how or where I saw the change, I do appreciate the hack! :) --qedk (tc) 17:25, 12 August 2019 (UTC)
Thanks, @DannyS712 and Legoktm:! --qedk (t c) 19:51, 19 August 2019 (UTC)

Adjusting edit window size[edit]

When editing in wikitext mode, is there a way to set the height of the edit window? Default seems to be 26 lines, and I almost always want about double that, especially when editing long articles or tables. I suppose there is a JS or CSS variable that can be adjusted somewhere? Also, this setting should be added to Special:Preferences, under the Editing tab, Editor section, to help non-technical users. — JFG talk 07:57, 12 August 2019 (UTC)

This will double the viewport:
.mw-editform #wpTextbox1 { max-height: none; }
#wpTextbox1 { height: 200em; }Ammarpad (talk) 08:25, 12 August 2019 (UTC)
More like quadrupled it… Thanks for the tip! Any idea where to suggest an easy setting for non-techies? — JFG talk 09:48, 12 August 2019 (UTC)
AFAIR, a little while back you could change this in your Preferences. I don't know why it was removed. —Bruce1eetalk 10:17, 12 August 2019 (UTC)
@JFG:, that's true, I forgot that the size I doubled was for the default 'maximum height' of the viewport. Also note that the text area is already resizable on the fly by clicking and dragging the two diagonal lines at the bottom right corner. Actually that way is more flexible than using fixed size from your personal CSS. On your second question, that'd be making a gadget to allow one-click from Preferences page, but this is not something a lot of people are looking for, so it's not good candidate for that. Also as Bruce1ee said, it used to be somewhere on that page but I believe it must have been removed during the effort to get rid of seldom-used preferences. – Ammarpad (talk) 11:59, 12 August 2019 (UTC)
See phab:T26430 and phab:T155153 for the removal. PrimeHunter (talk) 12:20, 12 August 2019 (UTC)
Right: I was always losing time to drag that edit window bigger before I could work. Thanks for the pointers to relevant phab tickets. — JFG talk 12:32, 12 August 2019 (UTC)
This has been covered several times here at VPT, see for example Wikipedia:Village pump (technical)/Archive 153#Edit box size, Wikipedia:Village pump (technical)/Archive 169#Hard to scroll down in lower right corner of edit window, and it's also buried in Wikipedia:Village pump (technical)/Archive 171#Separate buttons for single and double bracket links in the editing toolbar (my reply of 23:48, 15 November 2018). There are other related threads in the archives. --Redrose64 🌹 (talk) 19:51, 12 August 2019 (UTC)
Mmmhh… If that's a perennial question here at VPT, perhaps the idea of re-instating a visible user setting might be answering some latent demand. First phab ticket was about columns, and that's probably not necessary given adaptive width, but in the second ticket the setting for rows was apparently discarded in one lump with the columns. Shall ww re-instate the rows setting? — JFG talk 21:30, 12 August 2019 (UTC)

Tech News: 2019-33[edit]

18:19, 12 August 2019 (UTC)

Unexpectedly different behavior depending on location of userscript's source code[edit]

After extensive testing, I have documented a weird behavior that in rare circumstances will disable Template:Show button. There appears to be three conditions required for this to happen, and one of these conditions is just having the snippet of code in my common.cs file, as opposed to being in one of my subpages and imported to my common.js. Intuitively, I would expect identical behavior, but this is not the case. Details, and the discussion, can be found at the javascript project talk page in thread Importscript vs just putting code in common.js NewsAndEventsGuy (talk) 18:59, 12 August 2019 (UTC)

Javascript is loaded and executed in different order in this two cases. What is imported with importScript is executed probably in the end. Ruslik_Zero 09:09, 13 August 2019 (UTC)
thanks for the debugging lead. NewsAndEventsGuy (talk) 10:42, 13 August 2019 (UTC)
@NewsAndEventsGuy: This might not be the answer you were looking for but we had a thread a few months back where an editor was asking about how to make scripts load in order and the general sentiment was that you can't guarantee behaviour in that manner. So, the only way would be to add manual sleeps and hope (!) that did the trick. Don't know why it could exactly apply here but I just thought I'd mention. --qedk (t c) 07:24, 15 August 2019 (UTC)
I like thinkers who cast wide nets when these mysteries pop up, thanks. NewsAndEventsGuy (talk) 11:10, 15 August 2019 (UTC)

Review of new articles and Google/Wiki search[edit]

Why new articles if not reviewed don't appear in Google search at all (as if non-indexed) and appear in Wiki search only when full name written? I guess there are some users who have reviewer user rights but it seems they miss to review some articles. I created several articles with my extended confirmed account and they stayed on Wikipedia but don't appear in searches for months. Do I need to request somewhere special for it* to be done or ask some user who already did it* once only for one of 'my' articles (*review for each article)? Thanks. -- (talk) 05:40, 13 August 2019 (UTC)

See Wikipedia:Controlling_search_engine_indexing#Indexing_of_articles_("mainspace"). — xaosflux Talk 11:08, 13 August 2019 (UTC)
Thank you. -- (talk) 13:26, 13 August 2019 (UTC)

VTE links not opening on mobile[edit]

Is it intended that VTE links for nav templatrs only activate tooltip with link name unlinked? I think they should normally lead to each link target (view for template page, talk for its talk page and edit for edit window for template in question). -- (talk) 05:44, 13 August 2019 (UTC)

Nav templates usually aren't displayed in mobile but when they are, like on the template page, the links work for me. Please link an example and name your mobile device or browser. PrimeHunter (talk) 12:55, 13 August 2019 (UTC)
Please identify a problem (and fix it if it's not hard for you) for sr:Румунски језик#Спољашње везе. Probably navbox template should be updated there or some MediaWiki. Those English in your example are working for me; I use latest Samsung Internet browser, and view the article in desktop view on a mobile device. -- (talk) 13:23, 13 August 2019 (UTC)
I don't have an Android device but can reproduce the issue on an iPad. sr:User:PrimeHunter/sandbox has the code [[X|<abbr title="tooltip">V</abbr>]]. On an iPad I see underlining with dots and see "tooltip" when I click it but don't go anywhere. The same code here: V. On an iPad I cannot see "tooltip" but I go to X when I click it. I don't know what makes the difference. PrimeHunter (talk) 14:54, 13 August 2019 (UTC)
You mean you don't know why one doesn't go anywhere but sees only tooltip? I think something is wrong with sr:Модул:Navbar or some .css/.js MediaWiki page is not updated on sr.wikipedia. Maybe p.addItem function in sr:Модул:Navbar is not working properly but after comparing Navbox and Navbar templates and modules to that on English Wikipedia I cannot notice content difference except translations. Maybe Cyrillic translation makes problem? I don't known why it works here in your example with Template:Seasons but not with sr.wikipedia navbox template links... If someone else can help, please help. --Obsuser (talk) 17:32, 13 August 2019 (UTC)
I don't use a template, module or non-Latin characters at sr:User:PrimeHunter/sandbox. The page only contains the mentioned code: [[X|<abbr title="tooltip">V</abbr>]]. This simplified example gives a different result at srwiki and enwiki on an iPad. The navbox makes code of this form with abbr inside a wikilink. I simplified the navbox output as much as possible while still producing the issue. PrimeHunter (talk) 19:01, 13 August 2019 (UTC)
Yes, but why it gives a different result at srwiki and enwiki? --Obsuser (talk) 19:13, 13 August 2019 (UTC)
That's the question. [[X|<abbr title="tooltip">V</abbr>]] produces a working link on iPad in three other tested languages zh, de, da. It works with Without safemode it fails both logged in and out at srwiki. It also fails at wikt:sr: while it works at wikt:en:. PrimeHunter (talk) 20:13, 13 August 2019 (UTC)
It's caused by the default gadget sr:MediaWiki:Gadget-ReferenceTooltips.js. enwiki had the same issue at MediaWiki talk:Gadget-ReferenceTooltips.js#Interference with links on touchscreen, fixed by [5]. The Serbian gadget can only be edited by a Serbian interface administrator. The latest edits were made by User:Ранко Николић. PrimeHunter (talk) 08:17, 15 August 2019 (UTC)
@PrimeHunter: Thank you very much for that info. But if you check sr:Special:Diff/21299776/22084018 you will see that that update has already been done here (you can check diffs, only textual translations are made and code is same); however, the problem is still present as we see... Is it something else problem with this? [Please ping me...] --Obsuser (talk) 00:01, 17 August 2019 (UTC)

────────────────────── @PrimeHunter: They are working actually now for me, same behaviour as English Wikipedia when logged out and on Samsung Internet latest. Only that on both sites tooltip is displayed first with "View this template" etc. messages, this could be probably prevented somehow because no use after one clicks it on mobile, because one goes to the link destination anyhow... Btw, Template:Outdent displays one level or so less on mobile (I used 9 right above and upper vertical part is significantly left of the last paragraph's bottom left). -- (talk) 07:41, 17 August 2019 (UTC)

And I'm sorry for a such comment (the one prior to the previous one) because I didn't see/notice that the update on gadgets's page was done on 15 August, day or two before i.e. after this thread began (13 August morning/dawn). Ranko Nikolić probably got pinged after 08:17, 15 August 2019 (UTC) comment and then reacted to solve the problem. -- (talk) 07:51, 17 August 2019 (UTC)

Yes, he implemented the fix 21 minutes after my ping. It works for me now on iPad. Are you Obsuser or is he a different user who may still see the problem? PrimeHunter (talk) 08:13, 17 August 2019 (UTC)

Conflict between Template:Shortcut, lists and Microsoft[edit]

FYI: Pointer to relevant discussion elsewhere.

Please see Template talk:Shortcut#When in a list item, Edge and IE have a sad day. --Redrose64 🌹 (talk) 20:39, 13 August 2019 (UTC)

How to prevent VisualEditor from automatically loading when clicking red links?[edit]

Title says it all. VE often loads automatically when I open a red link which is annoying because most of the time, I do so to see the deleted edits. I can't seem to find a preference for it though. Regards SoWhy 07:31, 14 August 2019 (UTC)

This is the default behaviour for clicking all redlinks in both VE and Source editor (except Userpage redlink on mobile). There's a phab:T211379 asking to change this and there are comments that this is by design. – Ammarpad (talk) 08:21, 14 August 2019 (UTC)
@Ammarpad: Thanks for the phab-link! I dug up a snippet at T195914 that prevents it (thanks to Classicwiki). Regards SoWhy 09:13, 14 August 2019 (UTC)
@SoWhy: have you tried setting "Temporarily disable the visual editor while it is in beta" in Special:Preferences#mw-prefsection-editing? I have that set and never get the visual editor unless I specifically switch to it. — xaosflux Talk 11:39, 14 August 2019 (UTC)
No, because I actually use it quite extensively and that setting disables the links to the VE and the visual edit tabs that I use. But with the user script Classicwiki provided at phab, the problem is solved. Regards SoWhy 11:58, 14 August 2019 (UTC)
  • I described a related problem here (and opened T226267 on it). -- RoySmith (talk) 16:49, 14 August 2019 (UTC)

Tools for history[edit]


Vchimpanzee • talk • contributions • 17:55, 14 August 2019 (UTC)

I didn't get a response here about why Help:Page history didn't have directions for entering a specific date such as November 8, 2019. I thought there was such a feature..— Vchimpanzee • talk • contributions • 14:49, 14 August 2019 (UTC)

Once you click on the input field a placeholder text YYYY-MM-DD and calendar widget will appear (assuming Javascript is on). That's enough visual cue to tell you what you should do next. – Ammarpad (talk) 18:01, 14 August 2019 (UTC)

Converting from one citation template to another (visual editor)?[edit]

Is there an easy way to convert one citation template to the correct type, in VE? People commonly just use the default {{Cite}} instead of, for example, {{Cite news}}. I haven't found a good way to fix that up other than to create a whole new citation and delete the old one. Which is especially annoying when it's used more than once, as in this example. It seems like it would be straight-forward to have a tool which took the existing citation and did a first pass at converting it into a different subtype, copying over whatever fields exist in both. Does such a tool exist? -- RoySmith (talk) 16:57, 14 August 2019 (UTC)

Pretty sure this is phab:T97936, and a harder problem over here phab:T87271. --Izno (talk) 03:34, 15 August 2019 (UTC)
Yeah, T87271 is exactly what I'm talking about. Thanks. -- RoySmith (talk) 03:48, 15 August 2019 (UTC)

Account creations appear to be getting throttled to 2/day for editors[edit]

Hello all, if you are running in to this, it appears to be a temporary issue. Discussion and linked phab tickets are available at Wikipedia_talk:Requests_for_permissions#T230304_and_account_creation_being_blocked if you want to follow for more information as it becomes available. Best regards, — xaosflux Talk 04:21, 15 August 2019 (UTC)


Hi - I find the RefToolbar very useful, but I would like to request an additional feature. In the Web Citation popover, can we please have a checkbox (or a select menu) to specify deadurl=yes/no? I can fill in Archive URL and Archive Date in the form, but after I have inserted the reference into the article, I have to go in and type the "deadurl" bit manually, which is a bit fiddly. Does anyone know how to get someone to add this? Thanks. Cnbrb (talk) 10:07, 15 August 2019 (UTC)

CSS for tables sabotaged?[edit]

Time in Russia
     KALT Kaliningrad Time UTC+2 (MSK−1)
     MSK Moscow Time UTC+3 (MSK±0)
     SAMT Samara Time UTC+4 (MSK+1)
     YEKT Yekaterinburg Time UTC+5 (MSK+2)
     OMST Omsk Time UTC+6 (MSK+3)
     KRAT Krasnoyarsk Time UTC+7 (MSK+4)
     IRKT Irkutsk Time UTC+8 (MSK+5)
     YAKT Yakutsk Time UTC+9 (MSK+6)
     VLAT Vladivostok Time UTC+10 (MSK+7)
     MAGT Magadan Time UTC+11 (MSK+8)
     PETT Kamchatka Time UTC+12 (MSK+9)

The content of {{time zones of Russia}} is nastily clipped in Vector. In Monobook I see it differently depending on desktop. I suspect that some quick hands without feedback scrabbled in style sheets, but am unwilling to investigate. There are scores of people with privileges here, while I have none. Incnis Mrsi (talk) 10:51, 15 August 2019 (UTC)

I'm actually shocked the template works at all; I've never seen anyone put a table inside of a file caption. I don't see any issue though, any of Monobook, Vector, or Timeless. --Izno (talk) 11:48, 15 August 2019 (UTC)
Caption with a loooooooooooooooooooooooooooooooooooooooooooooooooong word
It also looks fine to me in Vector. Captions don't make horizontal scrollbars for wide content so I can imagine the right side being cut off for some users who don't have room for all the table columns. If this is what you mean by ""nastily clipped" then it's not specific to tables. It happens for me in the example image with "Caption with a loooooooooooooooooooooooooooooooooooooooooooooooooong word". I see three caption lines with the middle cut off at "looooooooooooooooooooooooo". PrimeHunter (talk) 12:03, 15 August 2019 (UTC)
The image in {{time zones of Russia}} is 300px. The smallest size where I see the full caption in Vector is 272px. We could increase the image to 350px to reduce the risk of problems. There may still be users with too large fonts but probably few. PrimeHunter (talk) 12:15, 15 August 2019 (UTC)
Thanks, I missed that the template was foolishly redesigned during last years. Should the table be extracted from the caption? Incnis Mrsi (talk) 13:45, 15 August 2019 (UTC)
I think that would be a good idea. More guaranteed not to break that way. --Izno (talk) 13:56, 15 August 2019 (UTC)
With 300px image
Time in Russia
     KALT Kaliningrad Time UTC+2 (MSK−1)
     MSK Moscow Time UTC+3 (MSK±0)
     SAMT Samara Time UTC+4 (MSK+1)
     YEKT Yekaterinburg Time UTC+5 (MSK+2)
     OMST Omsk Time UTC+6 (MSK+3)
     KRAT Krasnoyarsk Time UTC+7 (MSK+4)
     IRKT Irkutsk Time UTC+8 (MSK+5)
     YAKT Yakutsk Time UTC+9 (MSK+6)
     VLAT Vladivostok Time UTC+10 (MSK+7)
     MAGT Magadan Time UTC+11 (MSK+8)
     PETT Kamchatka Time UTC+12 (MSK+9)
With 190px image
Time in Russia
     KALT Kaliningrad Time UTC+2 (MSK−1)
     MSK Moscow Time UTC+3 (MSK±0)
     SAMT Samara Time UTC+4 (MSK+1)
     YEKT Yekaterinburg Time UTC+5 (MSK+2)
     OMST Omsk Time UTC+6 (MSK+3)
     KRAT Krasnoyarsk Time UTC+7 (MSK+4)
     IRKT Irkutsk Time UTC+8 (MSK+5)
     YAKT Yakutsk Time UTC+9 (MSK+6)
     VLAT Vladivostok Time UTC+10 (MSK+7)
     MAGT Magadan Time UTC+11 (MSK+8)
     PETT Kamchatka Time UTC+12 (MSK+9)
Tables in captions work fine as long as they aren't forced to be too wide for the image. I added a 300px and 190px version where a &nbsp; is removed to allow wrapping in "Yekaterinburg Time", and UTC/MSK is in the same cell to allow wrapping there. I see the whole caption at 190px and think almost everybody does at 300px. It's less pretty when cells wrap but I think it would be worse if there was no table but just whole unaligned lines which wrap at the end of the line. And most readers probably don't get wrapping at 300px but do get good formatting with aligned columns. PrimeHunter (talk) 16:41, 15 August 2019 (UTC)
You could also put the image in the (new) top row of the table, and thus not have to worry about how |thumb= behaves at all. Whatamidoing (WMF) (talk) 20:24, 20 August 2019 (UTC)

Preferences edit request[edit]

Don't know where else to put this. At preferences, under "Gadgets", there is a checkbox related to the Watchlist. EDIT REQUEST, please add text under the watchlist tab so folks configuring watchlists can more easily find the watchlist bold toggle under the gadgets tab. (I spent 90 minutes today trying to figure out why bold wasn't working but never thought to look under gadgets... Thanks NewsAndEventsGuy (talk) 13:52, 15 August 2019 (UTC)

You mean: "Display pages on your watchlist that have changed since your last visit in bold (see customizing watchlists for more options)"? Ruslik_Zero 14:20, 15 August 2019 (UTC)
Yes... that quote is under the gadgets tab, so we're coverted going GADGETS >>>to>>> WATCHLIST. But if one starts configuring their watchlist under "watchlist" - as most preferences noobs probably do - there is no text pointing at the gadget. If such text were added, we would help people know that there is more watchlist tweaking if they go the other way, WATCHLIST >>>to>>> GADGET. NewsAndEventsGuy (talk) 14:31, 15 August 2019 (UTC)
I don't think that's possible. Gadgets are local, user-written scripts. The rest of Special:Preferences is from MediaWiki itself. User:TheDJ probably remembers what this script does – maybe turns off MediaWiki's default bold, and then turns it back on, or something like that? Whatamidoing (WMF) (talk) 20:27, 20 August 2019 (UTC)

Template:OS coord[edit]

As some of you may be aware, {{OS coord}} (and related templates) has been out to lunch since about April. It's maintained by RHaworth (talk · contribs), who has posted an appeal at Template talk:OS coord#Getting back up 2019. All suggestions welcome there. --Redrose64 🌹 (talk) 14:56, 15 August 2019 (UTC)

Flag of Greece[edit]

Have you noticed that Greece's flag is not appearing? See for example 2019–20 UEFA Champions League. Also see Template:Country data Greece. (talk) 18:29, 15 August 2019 (UTC)

 Works for me is it only in a certain browser you see this problem? — xaosflux Talk 18:39, 15 August 2019 (UTC)

Only with Google chrome I have the problem. I have just checked it with Firefox and is ok. (talk) 18:45, 15 August 2019 (UTC)

My Chrome's fine; try clearing cache? --Golbez (talk) 18:58, 15 August 2019 (UTC)
If it's bad cache some on this page will work and others not. -- GreenC 19:00, 15 August 2019 (UTC)

Wikipedia Beta 'Jump To' tool not functioning in Mobile View[edit]

So, I have Wikipedia Beta enabled in Mobile View on my iPad iPhone 5S, with a nice 'Tick' suggesting the 'Jump To Top' function is also enabled. But I'm not seeing any form of floating button to help me move back to the top. Nor can I easily find any url to this documented function to assist me in report the issue - hence my post here. By way of example, navigating through WP:ANI in mobile view is a real struggle, and would be helped by this tool, whereas I've already added to the {{skip to top and bottom}} template to The Teahouse which makes life so much easier when navigating up and down, whether in desktop or mobile view. I'd love to get that similar functionality working on all article pages when in Mobile View. Many thanks, Nick Moyes (talk) 23:30, 15 August 2019 (UTC)

@Nick Moyes: Weird. I am using the beta version and this floating jump to top button is fully working on my Chrome Dev 77. What browser you are using? Masum Reza📞 05:33, 16 August 2019 (UTC)
Hi Masumrezarock100, I'm using the iPhone's default Safari browser. Nick Moyes (talk) 06:51, 16 August 2019 (UTC)
@Nick Moyes: Try changing your browser. It's most likely because of lack of browser support. Does this kind of thing happened to you before or is it new? You can report about this at mw:Talk:Reading/Web/Advanced_mobile_contributions. Though it's the talk page of AMC mode not Wikipedia beta. Masum Reza📞 07:06, 16 August 2019 (UTC)
@Masumrezarock100: I don't know when the jump-to-top button was implemented, but I've only just switched from working on my phone in desktop view to experimenting with it in mobile view (in order to try out the Advanced Contributions Mode). I'll check your helpful link and report the Safari browser issue. Thanks, Nick Moyes (talk) 12:06, 16 August 2019 (UTC)

Is anyone up to the job of helping me update our page on downtime?[edit]

Wikipedia:Downtime is currently inactive and is retained for historical reference. I think it would be worthwhile to revive it. Does anyone know where I can find the information I would need to do that? My impression is that in recent years we have only had brief planned downtime while various upgrades are made, but I would like to see a page documenting the great job the server wranglers are doing. --Guy Macon (talk) 23:32, 15 August 2019 (UTC)

@Guy Macon: wikitech:Incident documentation. This includes a lot of services that don't effect readers here on enwiki, though. See also the "Production excellence" reports on Release Engineering Team blog. MusikAnimal talk 14:57, 16 August 2019 (UTC)
Thanks! I think I can separate out the actual outages and update the page with that. Might take a week or so because of that pesky real life... :) --Guy Macon (talk) 15:02, 16 August 2019 (UTC)

Disabling HTML comments for drafts?[edit]

I've seen several instances of draft authors inserting HTML comments with their replies to reviews. I assume what's going on is that instead of using the AFCH Comment button, they've accidentally discovered the "Insert comment" feature of Visual Editor. If you're new at all this, it's a perfectly understandable mistake, and leads to all sorts of confusion. Is there some way we can disable the "Insert comment" menu item in VE when editing a draft? -- RoySmith (talk) 12:54, 16 August 2019 (UTC)

@RoySmith: disabling HTML comments in Draft space all together would be a bad idea (for example they are often used to comment out categories being drafted). Can you provide a few diffs where you think this problem is being introduced though? — xaosflux Talk 13:02, 16 August 2019 (UTC)
Most recently, here, immediately followed by an attempt to fix the problem; I assume the nowiki tags got added automatically as part of some copy-paste operation. This isn't the first time I've seen stuff like this, but I'd have to do a lot of digging to find other examples. Maybe the "Insert comment" menu item should be disabled in VE for all new editors, with a preferences checkbox to enable it? It really is an advanced feature, that's not likely to be needed by new editors. -- RoySmith (talk) 13:21, 16 August 2019 (UTC)
I don't think there is project-level control of those settings (just like with the "index/noindex" control in there that is virtually useless. — xaosflux Talk 13:37, 16 August 2019 (UTC)
If possible, I would prefer that the name be changed to "insert invisible comment" with a help page created at WP:HTML Comment explaining when and why one might use the AFCH Comment button and when and why one might use the invisible comment button. We could even add a "are you sure?" extra step befor an HTML comment is placed.
In general, I don't like disabling features when a warning or explanation can do the job. --Guy Macon (talk) 13:47, 16 August 2019 (UTC)
Having the editor work differently in draft space and main space does not strike me as a desirable feature. Explaining the buttons better seems superior to removing them. —Kusma (t·c) 13:58, 16 August 2019 (UTC)
@Kusma and Guy Macon: we could change the label from "Comment" to something else in these messages. It doesn't look like it supports wikilinks or much help text there though. — xaosflux Talk 14:03, 16 August 2019 (UTC)
Changing "comment" to "invisible comment" seems like an uncontroversial change that we can make right now. Does anyone object?
Next, is it possible to put up a warning/explanation that the user only sees when they click on that button? --Guy Macon (talk) 14:28, 16 August 2019 (UTC)
Submitters of drafts don't have an AFCH Comment button unless they've turned on "Yet Another AFC Helper Script" in their gadget preferences, which they are extremely unlikely to have done. To keep them from thinking that the right way to respond to a reviewer comment is with <!-- Hidden text -->, it would be better to change VE's insert menu item from "Comment" to "Hidden text". "Comment" (or "Invisible comment") makes sense to computer programmers, but most users of VE aren't computer programmers. The text
  • Symbol opinion vote.svg Comment: , inserted by template {{AFC comment}}, could also be changed to something else. If AFCH were modified to place the comments on the talk page, reviewer comments might not need any introductory symbol and word. The argument against using the talk page has always been that newbies are too clueless to find the talk page, but perhaps it's worth investing the effort to train them to do so. --Worldbruce (talk) 14:33, 16 August 2019 (UTC)
  • Thanks everybody for your comments. I agree that (despite it being my initial recommendation), having VE work differently in drafts than in other namespaces would be confusing. I like the idea of changing the system messages to say "invisible comment" instead of just "comment". Even if naive newbies may not understand what that means, it should certainly be a clue that this is probably not what they want. It may not be the perfect, or final, fix, but it's easy to do and gets us most of the way there. Low hanging fruit, as they say. -- RoySmith (talk) 01:46, 17 August 2019 (UTC)
  • I've changed the system messages to say "Invisible comment" - if there are any issues please let me know. — xaosflux Talk 20:40, 20 August 2019 (UTC)

Place important links on top instead[edit]

Placing important links on top will be more helpful.

Privacy policy and disclaimers are important and should be placed on top. Monniasza talk 14:19, 17 August 2019 (UTC)

People do not come here to read policy and disclaimers. --Izno (talk) 14:34, 17 August 2019 (UTC)

Template with right side overflow, a temp fix?[edit]

Greetings, for Template {{Patriarchs of Constantinople}} the wikilinks on right side were spilling beyond the right margin. If I changed my browser to 80-percent (very small text) the problem would go away. To get 100-percent size text, I added a blank image (|image= [[image:Pix.gif|right|10px]]). This appears to have solved the issue. Wondering if this a temporary solution or is there a better way for this navbox? JoeHebda (talk) 17:44, 17 August 2019 (UTC)

{{Navbox}} adds the nowraplinks class to the table. That can cause overflow problems if the title includes a long link text, even when it looks like there should be room for it. I see the issue you describe at some zoom levels both before and after your solution although it does work at more zoom levels after. I think the override |titleclass = wraplinks is a better solution. PrimeHunter (talk) 21:27, 17 August 2019 (UTC)
 Done - Thanks PrimeHunter for the titleclass solution. Removing the right side image adds more Navbox space for the links. I've changed above template and a few large templates. Regards, JoeHebda (talk) 13:18, 18 August 2019 (UTC)

Getting IP-specific or different-range block logs for an IP[edit]

When an account is blocked for a second (or more) time, the pink box that lists the current block in Special:Contributions has a "View full log" link to see the previous block activity. If the account is an anon IP and the block is a rangeblock, then that link is for that same range (see Special:Contributions/2601:586:400:833A:FD78:71BE:47B5:5110, who is covered by a /64 block, and its "View ful log"). Using the "block log" link near the top of the page, I can see there is also historical block activity related to that specific IP ([6]). However, there is no way to find the historical rangeblock info once it expires unless one knows to look for the /64 itself (i.e., that it was a /64 rather than some other range, and that there might have also been other size ranges). Is there a way to look up all previous blocks that apply to a certain IP or small range, including all larger sizes? DMacks (talk) 12:10, 18 August 2019 (UTC)

toolforge:rangeblockfinder works for finding range blocks for an IPv4. — JJMC89(T·C) 22:10, 18 August 2019 (UTC)
This is phab:T146628 MusikAnimal talk 02:45, 19 August 2019 (UTC)
Thanks! That seems to be going in the opposite direction (subranges of given range) than I want (superset-ranges of given), but I added a note about this variation there. DMacks (talk) 03:09, 19 August 2019 (UTC)

Module that can handle MW timestamps[edit]

Hi all. I am curious if there exists a module that can take a MW timestamp (such as 20190818143148) as an input and return a formatted string (such as "18 Aug 2019, 14:31") as the output. Please {{ping}} me when responding hujiTALK 15:17, 18 August 2019 (UTC)

@Huji: Does os.time work for you? --Izno (talk) 15:28, 18 August 2019 (UTC)
@Izno: it probably would; but instead of writing a new module (which woudl obviously use os.time), I was wondering if I could use an existing one. Lua is not my strong suit after all. hujiTALK 18:53, 18 August 2019 (UTC)
Turns out the #time parser function accepts timestamps as an input. I will use that. hujiTALK 19:34, 18 August 2019 (UTC)

Picking a draft to review: RandomInCategory isn't very random[edit]

I've noticed that when I use Special:RandomInCategory/Pending AfC submissions, I see the same pages over and over. I found some threads (here and here) that explain about how RandomInCategory works (i.e. indexing pre-generated page_random values). I get that it's fast, but boy, does it produce poor results. I just pulled up 25 "random" drafts, and got:

  1. Draft:Declan Meagher
  2. Draft:Gary Soulz
  3. Draft:Ananth Narayanan
  4. Draft:Frank Verboven
  5. Draft:Maths Time Joy
  6. Draft:Gary Soulz
  7. Draft:Ananth Narayanan
  8. Draft:Eni Vasili
  9. Draft:Shorts México - Mexico International Short Film Festival
  10. Category:Pending AfC submissions in userspace
  11. Draft:John Haze
  12. Draft:Alisha Rai (author)
  13. Draft:Leonardo3 Museum
  14. Draft:Wake. (2018 film)
  15. Category:Pending AfC submissions in article space
  16. Draft:Anastasiya Makarevich
  17. Draft:Alisha Rai (author)
  18. User:ItsYaBoiAustin/sandbox/Odyssey: Extraction
  19. Draft:Scott Stambach
  20. Draft:Christian Lillinger
  21. Draft:Gudula Naiga Basaza
  22. Draft:Scott Stambach
  23. Draft:Katherine Boyer
  24. Draft:Walter Ferguson
  25. Draft:Faryal Mehmood

Not only are there four duplicates:

  • Draft:Scott Stambach
  • Draft:Gary Soulz
  • Draft:Ananth Narayanan
  • Draft:Alisha Rai (author)

but two pairs of duplicates in the same order:

  • Draft:Gary Soulz
  • Draft:Ananth Narayanan

There's "approximately 4,581" entries in Category:Pending AfC submissions. You don't have to do any math (yes, I know about the birthday paradox) to decide that's abysmally bad randomness. I suspect the feature was originally intended to service the needs of somebody randomly browsing the encyclopedia. It's probably fine for that. For servicing a work queue, not so much.

Not only is this not very random, but the process tends towards increasingly less random results over time. The most likely draft to be selected by somebody trolling for work is the one with the largest gap in page_random values. So, that's the one that's most likely to either be deleted, or promoted to mainspace. Either of which results in an even larger page_random gap! Of course, the other side of that is when a new draft is created, it's most likely to fall into the largest existing gap.

My statistics-fu isn't strong enough to figure out if those two effects cancel each other out, but I did write a little python program to simulate adding and deleting drafts using a similar algorithm. Starting with an initial pool of 4000 drafts, I did 100,000 iterations of deleting a draft and adding another one. I found all the gaps, and printed the stdev of the gaps every 10,000 iterations:


That's pretty typical across many runs. That says to me (the self-professed statistical idiot) that the longer you manage the draft work queue with this process, the less uniform the gap distribution will become, and thus lead to the behavior I'm seeing.

Assuming the above makes any sense at all, I think we need a better way to manage the draft work queue.

-- RoySmith (talk) 17:57, 18 August 2019 (UTC)

Good catch! Would this be a good candidate for a Phabricator ticket? --Guy Macon (talk) 18:43, 18 August 2019 (UTC)
Huh! I am virtually never active on enwiki. I happened to open the thread right above this one and see this as a result. I also happen to be the person who wrote RandomInCategory!
I think it is best to move this to Phab. Essentially (if I understand it well) the problem is that page_random is (hopefully) uniformly distributed across all pages; but when thinking about a small category, its values will certainly not be uniformly distributed. There exist ways through which we could circumvent this, but I'm not sure if these ways are efficient enough to be adopted into MW source code. It is best to have that discussion in Phab, where more technical users can discuss its efficiency (or propose more efficient implementations of it). Please add me (Huji) on Phab once you create the task. hujiTALK 18:58, 18 August 2019 (UTC)
I'm happy to open a Phab ticket, but I'm not sure what the ticket should say. The problem isn't (I don't think) that RandomInCategory is broken. I think the current implementation actually a pretty good solution for its intended purpose, which I assume is driving the "Random article" link on the main page. It's just that how we use it for managing the draft work queue is not a good fit. -- RoySmith (talk) 19:11, 18 August 2019 (UTC)
(edit conflict)My philosophy is to describe the problem without making any assumptions as to what form the solution should take. I remember a toy I worked on a a while back (think very limited amount of RAM and processing power) where the complain was that a particular "random choice" didn't feel random enough. Upon talking to the play testers, the real complaint was the toy serving up the same random selection two or three times in a row. So instead of rewriting the RNG, I just had it remember the last eight results and "roll again" if the latest selection was on the list of recent results. My point is that the people reporting the problem didn't know that this was the solution, and instead asked me to "make the selection more random" I actually made it slighly less random, but I solved the real problem.
So just report the test results without any assumption about what the answer should be, and let the developers pick a solution. --Guy Macon (talk) 19:36, 18 August 2019 (UTC)
Created T230700 -- RoySmith (talk) 19:20, 18 August 2019 (UTC)

So just to clarify - RandomInCategory does not use page_random like Special:Random does. Instead it looks at the date the first and last page was added to the category, and then picks a random time somewhere between those two, in order to find a page. Since date added to a category is distributed non-uniformly, this is generally not random. At the time, it was felt that this method, although severely flawed was better than nothing. Bawolff (talk) 02:02, 20 August 2019 (UTC)

Oh, so that really explains what's going on. That's worse than using page_random. With page_random, the biggest gaps tend to get split into smaller ones as new pages get added to the category, as noted above. In fact, once I realized that, I no longer had much confidence that my analysis made sense, but the behavioral observation was still valid. If you're using date added, that's monotonically increasing. Existing gaps never get split, they just keep getting bigger as entries are removed from the category. The one nice thing is this tends to favor processing older entries first. -- RoySmith (talk) 19:43, 20 August 2019 (UTC)

Tech News: 2019-34[edit]

15:20, 19 August 2019 (UTC)

Format output of Template:To USD[edit]

Hi there, please can you assist me with formatting the output of Template:To USD to insert commas between thousands, in addition to accept input which has commas. I believe {{formatnum:}} will be of assistance. Thanks for your help in advance, {{u|waddie96}} {talk} 18:39, 19 August 2019 (UTC)

[A note for myself that the template help doc must be updated to match these changes, i.e. r/v recent additions]