This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
I would like to use this script when reviewing pending changes. However, when I see the pending changes, it only shows the diff, not the article with the changes implemented. Can an editor edit the my script so that it shows both the diff and article with the changes implemented? I don't know how to do it myself so I am asking for help. InterstellarityT 🌟 10:08, 21 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I have just recently been having an issue: When I hit the preview button to check my edits then hit the publish button I get an edit conflict. When this first happened I treated it as such and it posted twice. After that I have reloaded and see it is already posted by only hitting the preview button. I have never had this issue, that was not a legitimate edit conflict, so am at a lose. Otr500 (talk) 16:09, 24 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Yes, Jotamar, probably WP:BOTREQ, how many edits are you looking for? There will be many millions. Fist step might be to look for edits preceding those with an edit summary of "rvv". Another good place to look is the edits prior to User:ClueBot's edits.
What I have in mind is some sort of heuristic tool, capable of finding a short list of possible vandalazing editions that have not been reverted, in a group of pages, for instance, the pages under one category. In less popular, poorly maintained pages, it's not uncommon that such an edition can be easily reverted even after months or years, but first you have to find them, and that takes up a lot of time. --Jotamar (talk) 13:48, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Communication failure between the bot owner and the community at WT:CS1. I fixed the WZ-551 page that Gog the Mild edited and will leave it to that editor to similarly repair any other error caused by the tool.
This is IABot via Oauth request by Gog the Mild. It was due to some miscommunications, my fault, iabot has been patched/rebooted and will look into fixing the errors added onwiki. -- GreenC 19:36, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Edit conflict. I had just written:
Thank you Trappist the monk. That would have been from me clicking "Fix dead links" on the "Revision history" page and not checking the result thoroughly enough. I shall recheck my other recent clicks of that button.
You are good, it's ok now. Looks like the bug lasted 3hrs and somewhere between 100-200 articles. I might script a quick fix or request something at AWB request wouldn't worry about manually repairing. -- GreenC 19:48, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
The development of Wikidata Bridge has started. The goal is to allow Wikidata edits from Wikipedia. [3]
Problems
Sometimes pages load slowly for users routed to the Amsterdam data center. Investigation is in progress. [4]
Wikidata query service was overloaded between 11:50 UTC until 13:15 UTC on June 24. It has been fixed. [5]
Changes later this week
You will be able to read but not to edit all wikis for a short amount of time, on 3 July at 06:00 (UTC). This is to move a database. [6]
There is no deployment of a new version of MediaWiki on the wikis this week (calendar).
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 3 July at 15:00 (UTC). See how to join.
The edit said [[:de:Otto Kirn]]. This explicitly tells to link the German Wikipedia. {{Interlanguage link|Otto Kirn|de}}} could have been used instead to test for an English article called Otto Kirn. It would only have examined whether the page name exists and not whether it's in a Wikidata item. As far as I know we have no template for the latter. It is possible to pull information from Wikidata so maybe it could be added as a feature in {{Interlanguage link}}. I don't think it's possible for an English template to look up the Wikidata item for a German article so Q24529752 would probably have to be a parameter. A bot could be coded to automaticlly add the parameter when it's not supplied. PrimeHunter (talk) 21:12, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Could someone knowledgable comment here, centrally, on whether there are database issues beyond the apparently temporary ones outlined in the above Tech News, and if so, what are their extent and when do we think they will be resolved? It appears multiple bots have for some time not been running DB intensive tasks (such as certain Wikipedia:Database reports), and it is very difficult to parse through all the bot/report talkpage chatter to get a true picture of what is actually going on. Thanks in advance! UnitedStatesian (talk) 02:46, 2 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
The database replicas are undergoing maintenance (see T222978). This involves taking one replica host out of service at a time. The other two hosts then have increased load, which leads to replication lag and increased query time (previously long queries could fail to complete). Maintenance is usually ongoing during the week and paused over the weekends. I would expect this to be an ongoing issue for a while. I don't know how long the maintenance will take, but the DBAs are reaching the end of the maintenance one the first replica. The database items in the Tech News are unrelated. — JJMC89 (T·C) 05:29, 2 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
initially I turned to administrator regarding the issue, but unfortunetly he could not give an idea for solution. The details may be read there...Shortly, if I set it to list the changes back to 7 or 30 days, it is not working, just listing the last 250 changes, not more and I have as well no (previous/next) buttons...I need a solution, Thank You(KIENGIR (talk) 20:21, 1 July 2019 (UTC))(discussiontools-replybutton)[(discussiontools-replylink)]
Thank you it helped, I applied similar tweaks descibred there (in the detailed settings changing to 30 days and enabling 1000 entries as maximum). though, still I don't have 30 days, I assume mainly because of the 1000 entry limitation (I don't know where would be the url to tweak it higher). Thus practically I could go back two weeks, so my initial problem has been solved (going back between 4-7 days)...maybe as an important note for the others or the developers, even this worked only by unchecking the "Expand watchlist to show all changes, not just the most recent" in the Advanced Options...(initially at the first tweak attempt, I automatically checked this box assuming it is essential, but anything written above did not work until it was unchecked, ironically it had a contraproductive effect despite it's name...(KIENGIR (talk) 10:39, 2 July 2019 (UTC))(discussiontools-replybutton)[(discussiontools-replylink)]
Switching to Vector displays them properly, even though the CSS rules are virtually identical - the only differences are that the word "monobook" becomes "vector" in the first and third url(...) value. --Redrose64 🌹 (talk) 20:21, 25 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Ditto here, IE 11 in Windows. They were missing for a while, but now they've reappeared. I think they're blurrier than before, however. Could someone ping me and thank me for this edit, so I can see whether the number notifications look any different. Nyttend (talk) 23:53, 25 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Thank you. Things are somewhat different; the numbers looked normal, but when I clicked each one, it was momentarily surrounded by a little dark box. The same is true if I want to review past notifications and click either of the icons when I have nothing new. Nyttend (talk) 10:51, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Nyttend: You might be right about the extra blurriness, I'm not sure (I took some screenshots a few years ago: c:File:Vpt redrose64 alerts.PNG, c:File:Vpt redrose64 alerts2.PNG, c:File:Vpt redrose64 alerts3.PNG back when the car door was still in place, now replaced by the TV set icon). You're certainly right about the little dark box, it's blue and there are two for each icon, one enclosing the number and the other enclosing the icon.
Suffusion of Yellow, I've just realized that my problem persists on Meta. Somebody pinged me, to test, and all I got was a three-year-old thanks. Can I put your magic code somewhere to fix that? (And hopefully Commons, Swedish Wikipedia, etc etc — I assume it's everywhere.) Bishonen | talk 19:30, 29 June 2019 (UTC).(discussiontools-replybutton)[(discussiontools-replylink)]
@Bishonen: the problem on meta-wiki, (and most all other projects) should get cleaned up with the next release train. If it doesn't I'll put the hack on meta-wiki. If you need it urgently, you can hack your own monobook.css there (or just click a bit further to the left). — xaosfluxTalk 19:38, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above. — xaosfluxTalk 03:14, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I suppose I can put that code in my own css file, but I'd prefer that talk page link not to work over the wide screen space. I use trackpad shortcuts to move backward and forward through browser tab history a lot on Wikipedia. Having all the space to the right pretty much disallows moving forward in the history via that shortcut. Killiondude (talk) 22:35, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
For any of my over-the-top complaining on this, some of it is frustration - but I really would like to thank Catrope for their continuing efforts to resolve this. Last update, the width problem is fixed, but now there is an alignment issue with the areas to click (you have to click a little further to the left then you used to right now) - this is already reported to phab. — xaosfluxTalk 03:46, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Lugnuts: the 'talk link' problem should be fixed now (at least in monobook). If you are still seeing it in monobook can you gather some more details: hover over "log out" and look at what the link would be, then slowly move your mouse to the left (over contribus/wl/pref/ etc..) and see if you get sandbox, then your talk link. If it is out of alignment let us know? The link to the "user page" is somewhat overlapping with notifications (See above) but should work if you approach it from its left edge. — xaosfluxTalk 14:27, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I've just noticed that "Notices" now fills up most of the space between "DuncanHill" and "Talk", and "Alerts" partially overlaps "DuncanHill". I don't generally notice them unless I actually have an alert or a notice, as I use the blackscreen gadget and the words "Notices" and "Alerts" helpfully display in black text on a black background. Since these recent changes they have started shewing up in orange (like the other links at the top) but only when I point my mouse at them. DuncanHill (talk) 15:08, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Xaosflux: This fixes all the overlap issues for me, in FF67/Linux:
Thanks both, thanks and pings seem to shew up well and be clickable. Someday I'll get around to mentioning the incompatibility with the blackscreen gadget. I have to highlight the notification to read who it's from. But that's been like that for ever. DuncanHill (talk) 22:28, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4). Nthep (talk) 14:52, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Nthep: Same as the monobook issues, should be fully fixed at the end of the week/next week depending on how they're doing deployments. Unless you don't like how we fixed it once it does change, in which case do please tell me. -— Isarra༆ 15:55, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Someone has broken Thanks
Now when I thank someone, instead of it happening all in the history page, it takes me to another page to ask me if I want to thank them, then to yet another page saying I have thanked them, and leaves me there and not where I was to start with and with no apparent way back. I expect it's an "improvement", but it makes life harder. DuncanHill (talk) 20:53, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I've been having intermittent weirdness of another type. On "Show preview", I've been getting a message that the servers are busy. If I refresh, it works fine. But the error has repeated numerous times today. I've been wondering if it's the new version of MediaWiki that Tech News mentioned would be on all wikis as of today. — Maile (talk) 21:00, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
(ec)I went back and in the page history it did not shew me as having thanked the person I had thanked. I tried again, nothing happened, then tried again and it behaved normally. I think there's a log somewhere where I can see if it went through, but can't remember where. DuncanHill (talk) 21:03, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
This is not about thanks (I think), but I got first one, then two notifications today for apparently nothing. I mean, there's a little red "2" in the usual place, but when I look there's nothing new there. I think the second one may have been for AGK's mention of me here, since it turned up right as I was reading his motion, but I've no idea what the first one is. Anybody know what's going on? If an arb offers a motion to examine my conduct, and has as far as he knows pinged me about it, it would be nice to get that ping. Can I go somewhere to find it? Bishonen | talk 21:20, 27 June 2019 (UTC).(discussiontools-replybutton)[(discussiontools-replylink)]
There's a Thanks log at this link. I don't think there's a ping log. People shouldn't rely on pings as 1) they don't always work at the best of times, 2) it's very rarely the best of times, and 3) I think you can turn notifications off. DuncanHill (talk) 21:26, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Bishonen, this happened to me (also a Monobook user) when someone replied to me in a topic which was archived in the time between their reply and when I saw the notification. Ever since then, whenever I go to a wiki project for the first time, there's a red number for notifications, even when there are none (because the default preference is to show cross-wiki notifications). On the bright side, I can always tell if it's my first visit to a project. BlackcurrantTea (talk) 07:48, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
At the top of every Wikipedia page I open are my control tabs: Username, Alerts, Notifications, Talk, Sandbox, Preferences, Beta, Watchlist, Contributions, Log out.
There is a red number over my Alerts tab, and the tab isn't working. When I click on it, it shows all the Notifications, as does the Notifications tab.
@BullRangifer: The problem is that although the bell and TV set icons are still links, their hotspots have shifted to the left by about their own width plus a bit more. So the TV set's hotspot is now where the bell is displayed. Therefore, to activate the bell, you click a little to its left - just over the letters "fer" should do it. --Redrose64 🌹 (talk) 11:05, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I've worked out why the hotspots are overwide and overlapping. Whilst looking at DuncanHill's (unrelated) Blackskin problem with that gadget enabled, I happened to hover over the alerts icons - and behold! the text links "Alerts (1)" or "Notices (1)" become visible. It is those textual items that are invisibly appearing in front of the desired links. So to get the bell's link, you need to be to the left of the "N" of "Notices (1)". --Redrose64 🌹 (talk) 19:12, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
It'll be actually fixed here by the end of the week, or next week. Probably. Patch is merged; this is just the last place to get fixes when people aren't wildly swatting everything like lemurs. Mmm, lemurs. -— Isarra༆ 15:50, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Thanks to User:Isarra's efforts on Friday, we now have full fixes for the notification badge issues in the Monobook and Modern skins. About 15 minutes ago (at 23:36 UTC) I deployed the fixes for Monobook, these are now live on all wikis. I didn't deploy the fixes for Modern because those are a little more complicated and that skin isn't used as much as Monobook is. If I get a chance, I may be able to deploy those 24 hours from now, and otherwise they'll come with next week's regular weekly deployment train on Thursday July 11 (there is no train this week due to the July 4th holiday). Thanks to User:Isarra for writing proper fixes for these bugs, and to User:Xaosflux for putting interim fixes in MediaWiki:Monobook.css in the meantime. And, again, my apologies for this disruption; I was the reviewer on the change that broke this, and I should have caught the fact that it changed the badge structure and the main badge CSS but did not update the Monobook CSS to match. --Roan Kattouw (WMF) (talk) 00:02, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Or there needs to be a setting in preferences to allow this. Scrolling is a pain. Half the page has to be scrolled to click the "show preview" button.
Weird thing is that the edit window here does not have the "Edit summary (Briefly describe your changes)" toolbar. It only has the "common edit summaries" toolbar.
If you begin editing by using the "new section" tab, then no, you don't get an edit summary window. Instead, a standard edit summary is constructed for you, consisting of the name of the new section wrapped in /* ... */ markers plus the words "new section". The edit summary window only appears when editing an existing section, or the whole page. --Redrose64 🌹 (talk) 16:25, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
A related problem is that the wikitext edit window length is not remembered. I can drag it up or down in length. But when I open another article or talk page, and then open an edit window, it is back to being a very lengthy edit window.
This exacerbates the previous problem of the "Publish changes" toolbar being separated by almost half a page of edit summary and terms of use stuff.
@Timeshifter: It has previously been suggested (see e.g. this thread)) that a setting such as the above rule textarea {height:15em} should be made a user pref. Unfortunately, this is not feasible since a value of 15em is not suitable for every user - we do not know how high anybody else's screen is. --Redrose64 🌹 (talk) 18:30, 2 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Redrose64: Thanks. I see from that old thread that it was possible in the past to choose the size of the textarea. I vaguely remember that this existed at one time. You wrote in that old thread: "Each pref removed marginally improves page load time for logged-in users." Is it only prefs that are changed from default settings that effect page load time? If so, then the more preferences the better.
There should be a way to open up and activate a whole new set of preferences. That way newbs could start with a manageable set of preferences. Then over time, if desired, then people could look at other preferences. Without having to paste stuff into CSS and JS pages. People could make their own decision as to whether the marginal loss of page load speed was made up for by the improvements provided by the additional preferences. -- Timeshifter (talk) 02:53, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I wrote a query regarding CSD category counts being incorrect and SoWhy helpfully pointed me to archived threads on this board, like Category count wrong and several others with the same complaint going back to spring 2018. Editors responded by listing Phab tickets, like T200402, T195397, T221795 or T18036 (and there are probably more). I've checked all the different tickets that were mentioned in these threads on this common problem and they are either marked as a) closed, resolved, b) closed, duplicate or c) low priority. I don't see how this issue can be considered resolved when it continues to be a problem and it is disappointing to think that there is little to no chance that anyone will work on actually solving this problem. It's clear that a lot of work on this started last year, but then the ticket was mistakenly closed as resolved.
Is there any way to restart the process of review so that there is some investigation of this problem? Because as a "resolved, low priority" task, that means to me that it will never be examined again. LizRead!Talk! 23:35, 2 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
In Phabricator parlance "low priority" does not necessarily means the task is not important; quite the opposite at times. Phab:T195397 was closed as resolved because it was indeed resolved at the time, and when the problem resurfaces, it was not reopened since there are many other open tasks. Some were closed as duplicate, because they were what the label says; even here, I believe we don't like 'duplicate.' The main task now is at phab:T221795. However, (for me to not be too evasive) I admit the problem is not given any sense of urgency from the technical side, but that's easily explainable. To be frank, there's nothing broken if category count is not correct. The problem has been noticed since 2008 or possibly earlier, and with adhoc fixes, everyone moves on until it returns and annoys another person. It's something obscure and which almost entire Wikipedia readers probably don't use nor care about. The editors who care for it (the count) are few, and even fewer know the problem exists. I don't know any way to speed up this, except (may be) to lobby the team working on it in the task, but keeping in mind, even if you think it needs immediate solution, others may not see it that way. – Ammarpad (talk) 06:37, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I happened to notice that hundreds of links in hundreds of articles include fbclid=longstringofrandomlookingletters parameters. According to what I read, Facebook adds these to track users' browsing behavior. It works like this:
Let's assume I discover something on www.example.com/cooltopic.html and share this URL with a friend on Facebook: "HEY CHEK THIS OUT!!!!!!!11"
Facebook automatically adds a unique FaceBook CLick ID (fbclid) to every link that is passed through them by adding &fbclid=... or ?fbclid=... to it. This doesn't change the destination of the link i.e. the URL still works the same.
The friend decides to add my URL as a reference/link to Wikipedia. Except, now the URL will read www.example.com/cooltopic.html?fbclid=xyz123.
Thanks to their Click ID Facebook can now track the URL: If the link is emailed to a 3rd person, who sends it to a 4th via Whatsapp, Facebook recognizes the (modified) link as the one I originally shared with my friend, thus gathering data about which persons are communicating with whom.
If the destination site of the link (example.com) has added a like-button to their page then Facebook even gets notified whenever anyone follows the link, i.e. they will know exactly which visits to www.example.com are a consequence of my original communication with my friend. (They use this to find out who is a valuable influencer.)
Long story short, IMHO all fbclid=... should be deleted from all (current and future) references and links on Wikipedia, because
Facebook has no business tracking Wikipedia contributors or readers.
The huge fbclid=... strings make references harder to read and edit.
The fact that an Wikipedia article's reference's URL was passed through Facebook's infrastructure earlier is not relevant to the topic the article covers, so this information need not be preserved.
The links work just the same after deleting the fbclid parameter.
So it would be great if some Wikipedia wizard could program and unleash a bot for this? Please??
Supposedly there are also Google Click IDs and others, however I haven't found their 'additions' in links. Maybe there is already a bot in place filtering them out? Then this bot would just need a little expanding.
I hope this is the right place to ask. Someone at the Teahouse was kind enough to point me here.
I believe there's a bot that's removing them already, though in a gradual way as there's no immediate harm while they're here. I think the bot is also removing them not only from Facebook's URLs but similar ones from Amazon.com and the like. – Ammarpad (talk) 20:35, 30 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
There are 1700 pages, many of which will have several affected links (the article where this issue came to my attention has 8 of them). While I admire your diligence, I do think it's best to let the bot handle this. Please consider that doing such tedious work manually is very error-prone, if you accidentally remove a bit too little or too much the link won't work any more. Best regards, Jens (84.173.225.148 (talk) 23:54, 30 June 2019 (UTC))(discussiontools-replybutton)[(discussiontools-replylink)]
Ah- I'm not planning on doing them all, just however many I can get to today (also, I check all the links before I upload), but yeah this is definitely something that's best suited for a bot once that gets running again. TheAwesomeHwyh 00:07, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
It is easy to see that | is a permissible character to the right of the active | in a piped link. For example, [[red|green|blue]] produces the anchor text "green|blue" linking to the page red: green|blue.
In the lead sentence of the page Xiquets Copenhagen, however, the wikitext ([[Castell|{{lang|ca|castells}}]]) is obviously intended to produce the anchor text "castells" linking to the page Castell; but actually it does not produce a link at all, and most of the wikitext shows up as ordinary text in the article. If this is supposed to work as intended, perhaps someone can fix the bug. If it's intended not to work, perhaps someone can edit the article to do what is necessary to achieve the desired effect.
No, it is not possible to have both the 2010 and 2006 toolbar. You could however ask for an script that adds the missing buttons to the 2010 toolbar, which would be the hidden comment, quote and horizontal line.--Snaevar (talk) 16:53, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
The following questions have been copied from the Teahouse. The editor below has technical questions we are unable to answer there, and I'm hoping editors here can provide Airbornemihir with assistance.Orvilletalk 05:21, 4 July 2019 (UTC)
I'm aware that it's a good practice to leave edit summaries, but I'm nonetheless curious about the official Android app apparently preventing an edit from going through if the edit summary is left blank. Is this an intended limitation of the app, or is there something I'm missing?(discussiontools-replybutton)[(discussiontools-replylink)]
The above questions have been copied from the Teahouse. The editor above has technical questions we are unable to answer there, and I'm hoping knowledgeable editors here can provide Airbornemihir with assistance.Thank youOrvilletalk 05:21, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Airbornemihir: Uhm, are you sure you are using the latest version? I just published this edit without an edit summary using the official Wikipedia app for Android. Also, the app is technically able to show talk pages, but it treats them as "normal" articles. I think the article (List of Wikipedia mobile applications) is referring to the "View talk page" option placed at the bottom of every page—including talk pages... yep—which the app doesn't yet "handle." —RainFall 07:27, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@RainFall: Thanks, I've noticed too that talk page links open by default in a different app, which is probably the intended meaning as you said. Regarding blank edit summaries, do you not get stuck during the edit at the place where it asks "How did you improve the article?" I can't seem to move on from there without either picking one of the canned edit summaries or writing one myself. Airbornemihir (talk) 07:46, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I just noticed that the gap between lines in "Syntax highlighting" mode in the wikitext editor suddenly became wider. Was it a glitch of my browser not loading CSS properly, or did it actually change? —andrybak (talk) 21:37, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I guess andrybak was not editing a CSS page but just speculating that styling from some CSS file was not working properly when editing a normal wikitext page. If you refer to the highlighter marker button to the left of "Advanced" in a toolbar then it doesn't change spacing for me in Google Chrome 75.0.3770.100. PrimeHunter (talk) 09:43, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@PrimeHunter: Yes, but for me it has changed in the same mode ( turned on), but between different pages. It changed between two different gap sizes since then, so I think that it was just some networking issue when loading CSS. —andrybak (talk) 10:12, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
A user (Console.frog) noted that when searching for "life on earth" on Google, the Life article appears in the middle of page 1 under the title life on Earth. This expression appears several times in the article but I can't figure out why the correct title is not brought up, and more importantly why "life" is not capitalized properly. Do you think there is something on our side causing this? -- Luktalk 11:27, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Situation confirmed; here's what I see with a US IP:
life on Earth - Wikipedia
https://en.wikipedia.org/wiki/Life
Evidence suggests that life on Earth has existed for at least 3.5 billion years, with the oldest physical traces of life dating back 3.7 billion years; however, some theories, such as the Late Heavy Bombardment theory, suggest that life on Earth may have started even earlier, as early as 4.1–4.4 billion years ago, and ...
Evolutionary history of life · Timeline of the evolutionary ... · Earliest known life forms
Is there a bot or tool that can replace the phrase Kingdom of Hawaii to Hawaiian Kingdom across Wikipedia without having to edit each page and switch it over? This is just a logistical inquiry before a request for consensus for such a change. KAVEBEAR (talk) 21:01, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
To answer the technical question KAVEBEAR, no - assuming this phrase appears in the source text it would require creating another version of the source text for each page (which yes a bot could do, but that is how it would do it). The only way around that would have been if the name was actually a template that could be changed once. — xaosfluxTalk 13:19, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Not sure if this is the correct venue but the tooltip (hovertext) that logged-out readers see for Antananarivo stampede is stuck on an old incorrect version with the wrong date. This has been repeatedly pointed out at main-page errors but no one there knows how to fix it. The article was corrected on 28 June [8]. Any help appreciated as this is currently on the main page in the In the News section. Espresso Addict (talk) 23:34, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I hope this is an appropriate place to describe this concern. If not, please advise me where to express it. On my laptop I'd like to be able to set desktop to be my wikipedia preference, so it would be my permanent default view, and mobile view never come up on it. I am using Firefox 67.0.4 (64-bit) browser on Windows 8.1. The problem I encounter is that when using my laptop computer and searching for something via google, sometimes when I click on a wiki search-find I get a presentation of a wiki article which I have discovered to be a MOBILE wiki presentation, which I don't want. I now finally understand that I can go to the bottom of such an article and click on 'desktop', and I'll get a desktop view, and that setting will also obtain for other wiki articles until I turn my laptop off. But the next time I turn my laptop on, mobile views can again present from google searches, and I have no use for mobile style views. I would think desktop view should be able to be set in Preferences. If that can't be made available in Preferences, is there some other way that I could set DESKTOP to be my wikipedia permanent default view? UnderEducatedGeezer (talk) 23:22, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
As far as I know, Wikipedia can't automatically switch you from the mobile view to the desktop view. If you're on a phone, and go to the desktop version (en.wikipedia.org), you can be switched to the mobile version (en.m.wikipedia.org), but the other way around doesn't work. Therefore, if you click on a link from somewhere else on the internet to the mobile version (en.m.wikipedia.org), you stay on the mobile version. The easiest way to change this is to remove the .m from the URL. rchard2scout (talk) 10:13, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
That does not work. Trying to remove ".m" without using the appropriate option will redirect you back to the mobile view. The opposite is not true and from the desktop view (without the ".m") accessing the mobile view by simply adding .m is possible. Now, the easiest way to flip the views is to go to the footer of the page and click "Desktop view" or "Mobile view" as you want it. It's cookied, so it sticks for a while, but once the cookie expires, it will reset back to mobile view (if on mobile) and desktop view (if on desktop). Note that these options are incompatible with browser-provided "Enable desktop view" options and will not work on Wikipedia. --qedk (t 桜 c) 12:25, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
"It's cookied, so it sticks for a while" is a key bug for me. I made that explicit "Desktop view" setting because I wanted it that way, and it might be a pretty long page I have to scroll through to get to the bottom to (re)change it. My request is that either the cookie have a much longer expiration or that it can be handled by a site (rather than browser) pref. DMacks (talk) 16:47, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
You can make a JS script and add it to your MySkin.js, all you need to do is detect the current URL and if it contains, ".m" and go to the URL + "&mobileaction=toggle_view_desktop", essentially forcing the desktop view. --qedk (t 桜 c) 17:20, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
That doesn't quite match my experience: for me, just removing the m. is all it takes. On a desktop, that is. But if someone drops a link from the mobile site (like in a diff) and you click on it, then you get the mobile version. I like the script idea. Ivanvector (Talk/Edits) 17:27, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Yep, if the default view is desktop (as in, how the page first loads), that is how it will work, but instead if your default view is mobile, it will not work. --qedk (t 桜 c) 18:36, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I have a bookmark on my mobile phone that does not have the m. It sometimes takes me to the mobile site, and then I can click the Desktop-site link at the bottom of the page to switch to desktop mode. From then on, for a while, the bookmark takes me to Desktop. But then sometimes it (that same bookmark, with no m) reverts to mobile mode, and I have to click Desktop-site switch it, and then it will again stay that way but only for a while. DMacks (talk) 18:53, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
That's how it works for me too. Not a bookmark, but any wikipedia URL I try to load will initially (if I haven't clicked the Desktop link in some time) automatically redirect to the mobile page. Then clicking on the Desktop link will keep me in desktop mode for ... some time, two weeks or a month or so, unless I click on another mobile URL. This is the case whether I check the "always request desktop version" setting in my mobile browser. Above, I was referring only to desktop behaviour, and I have no idea about setting "default view", I didn't know that was a thing. Ivanvector (Talk/Edits) 18:58, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I often edit from my phone, but dislike the mobile view because it does not show all items on the page (specifically templates) and the incompatiblity with user scripts (none work). Therefore, I wish for pages to always display in desktop view. Senator2029“Talk” 10:55, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I often edit on my tablet, and occasionally for no apparent reason it will go to mobile view. This can happen even if I am currently looking at a page in desktop view and click a link on the page. It's very annoying. As DMacks said, sometimes it's a long page and not that easy to scroll to the bottom of the page. I'd love to have a preference (or even a js hack) that would disable mobile view while I'm logged in regardless of what device or browser I'm using. older ≠ wiser 19:04, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@DMacks, Ivanvector, Bkonrad, and Senator2029: Hey guys, so I hacked together a script since a lot of you said it was an issue, which should work, {{subst:lusc|User:QEDK/forcedesktop.js}}. Just paste this into your Special:MyPage/common.js and it should work. I've tried it on my mobile (Android 8.1, Chrome 75) and Desktop (Windows 10, Firefox 67) and it works alright. If you run into any issues, I can try to fix it, but my focus is on AI/ML which is kinda far from web development, but I will surely try to fix it. Hope I could help. Also please note, if the script works ideally, you will not be able to access the mobile site at all, until you remove the script (and purge your cache). --qedk (t 桜 c) 08:57, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
The page preview for final item (as I'm writing this) on the "In the News" list on the main page (the Antananarivo stampede) mentions it occurred on 26 July, despite the article (correctly) saying it was 26 June. Looking at mw:Page Previews, it just says it uses a portion of the opening paragraph, so I have no idea what's causing the discrepancy. Does anyone know why this is happening and/or how to fix this? Thanks, –Deacon Vorbis (carbon • videos) 20:50, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Currently, one of the most backlogged processes is Request an Account (ACC) , which exists mainly (though not entirely) for helping with 3 purposes: Those having trouble completing CAPTCHA; enabling the choosing of a username that is too similar to an existing username under certain circumstances & creating an account for those hindered by a rangeblock.
The current backlog on pending requests is 4 months.
In the last couple of months multiple editors have signed up to be ACC tool users, Tool users are signed up to the confidentiality agreement and meet various other criteria.
Currently here are limits, however, on both their ability to create accounts. Two options could ease their work.
Raise the local account creation rate limit from 4 to 10. The new limit only to extended-confirmed users to prevent any abusive behaviour from IPs.
Automatically grant account creator permission, on request, to new ACC tool users. This would allow them both to bypass the limit entirely, but would also let them ignore the antispoof and title blacklist when making accounts.
NOTE: Option 2 is broader than Option 1, however they do not completely overlap. Option 1 would allow any EC-confirmed editor to create up to 10 accounts per IP address, option 2 is specifically targeted at ACC-users. Thus participants can !vote for either/both/none of the options.
Survey: Account creator rights
Support for option 1 only. Speaking as an ACC administrator, I believe that automatically granting all new ACC tool users the account creator user right (option 2) would open the door for new tool users to potentially handle requests incorrectly and without limitations before it's caught and identified - which would not be a good thing at all. We need to have a limit for how many accounts that new tool users can create per day by default. When a tool user shows proficiency with handling requests correctly, they can apply for and (after approval by an ACC admin via a comment made to the request) be granted the account creator flag in order to remove those limits. Option 2 would remove the need for an ACC tool administrator to give their approval before an admin can grant the user rights to the requesting user. This approval is still necessary and absolutely needed. Raising the current limit of 4 creations per day to 10 creations per day would loosen the restrictions so that users can help take care of the current backlog of requests at ACC, while still being on a set limit during the time that they're learning and demonstrating their knowledge and proficiency with ACC tool user interface. This option is the best way to resolve the concerns expressed. :-) ~Oshwah~(talk)(contribs) 13:25, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Support option 1 as per my comment in the previous discussion. I also agree with Oshwah on automatically granting new users the ACC bit. The current method of granting the right after a couple weeks of activity allows the team to gauge the user's performance and whether or not they have learned the policies and procedures properly. Lowering the barrier further could lead to a problematic user potentially causing a lot more damage (no rate-limit, anti-spoof override, username title blacklist override) than they otherwise could if we had to manually grant those rights. On the other hand, when all is in order, granting them the right is usually quick and painless anyway. — AfroThundr (u · t · c) 14:04, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I appreciate the idea, but I just don't see how this implementation would be useful here, or how it would resolve any issues that the account creator flag wouldn't already resolve. If an ACC admin user can trust an ACC tool user enough to have no account creation limit, that admin user should also trust the tool user enough to be able to correctly and properly handle requests that tripped the antispoof extension and require a flagged user to override (and vice versa). ~Oshwah~(talk)(contribs) 14:45, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Support 1. After thinking about this a bit more, I'm not sure if tying the rate limit to extendedconfirmed would be possible. If not, I still think we should raise the limit, but maybe to 6 like it was before instead. The limit was lowered mainly for projects without 300 active local sysops who couldn't instantly respond to mass account creation. -- Ajraddatz (talk) 15:16, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Rights like PMR have increased limits for certain flags (in that case, page moves), this would just mean adding a flag like that to EC right holders. --qedk (t 桜 c) 15:23, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Yes, most ratelimits are determined on a per-account basis (or per IP for anonymous users). But I seem to remember account creations being different, and being specifically tied to the IP. I assume/hope that a defined higher ratelimit for extendedconfirmed would override that. And no need to tie it to a specific permission; it can be done for the group itself. -- Ajraddatz (talk) 22:58, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Yep, but that's a non-issue as far as devs are concerned. Delving into the issue of newer technical changes, from my experience talking to people on SRE/Deployment (and Anomie, TheDJ), technically unfeasible things are pretty rare and I have not seen requests getting turned down (rarely, if ever) with "MediaWiki does not support this", if it's a feature change, or some irreproducible bug, it's a different thing but for example, during the RfC for Template editor rights, a lot of people were worried about the tecnical changes but eventually it was done, with no big deal at all. That's how it is for most new things (and TE rights had a new protection level as well), so I would say a change would be technically feasible until a dev says exactly otherwise. --qedk (t 桜 c) 07:50, 16 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
With dev time almost anything is possible; my concern would be if the current software doesn't support the change, then we should be looking at easier options like raising the max number to 6 / IP as it used to be. Adding a new protection level is easy to do through the software. Fundamentally changing the account creation throttle might be more difficult. But agreed that we should ask rather than muse about things we know little about :-) -- Ajraddatz (talk) 01:03, 18 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
(ACC admin comment) I'm pretty sure option 1 isn't possible without development, i.e. it is not a simple configuration change. AFAICT, IP account creation limits can only be set as a count per interval with the noratelimit right being the only way for a user to bypass that limit. (mw:Manual:$wgAccountCreationThrottle) Oppose option 2 for the reasons outlined by Oshwah. Support returning the daily IP limit to 6 unless the Security Team provides a good reason that it needs to remain at 4. — JJMC89 (T·C) 05:50, 15 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Oppose I think 6 is the highest we should go with general limits on account creation per IP. Given that changing IP is rather trivial, the higher we go the greater the risk of abuse. If we raised the limit from 4 to 10, and a bad actor switches from their laptop to their cellular data network when they hit a limit, that is an additional 12 accounts they would be able to create. I think 4 was fine, 6 is okay, but anything higher I am not in favor of. I am not in support of option 2 for the reasons above. Wugapodes[thɑk][ˈkan.ˌʧɹɪbz] 19:05, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Nosebagbear: regarding your proposed options, and since this is VPT, can you explain the specific technical changes you are proposing - or is this more of a "let some developer figure it out" type of request? Is the "automatic" granting you are asking some sort of technical change you are proposing, or is it a procedural/policy change? — xaosfluxTalk 13:24, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
(edit conflict) @Xaosflux: - changing the rate limit is obviously possible. Whether it can be changed "in bands" to different protection levels is, I'm afraid, I query for those more technically savvy than me. If they say that's impossible (or akin), then this would need to be rethought. Nosebagbear (talk) 13:29, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Xaosflux - No. Requests that have tripped the anti-spoof extension make approximately 3.5% of all total requests at this time. Of those, users without the account creator flag can still see if the similar accounts are active, and decline the request if any of them are. The only time that a request requires a user with the account creator flag is when a request trips the antispoof extension and the similar accounts are all inactive. This means that the antispoof needs to be overridden, the request approved, and the account created. ~Oshwah~(talk)(contribs) 13:37, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
1997kB - Not a bad thought, but event coordinators can set new accounts as 'confirmed' using Special:UserRights, which is an ability that they don't need. Essentially, we'd be trading apples and oranges here if the concern is over access to some user rights they shouldn't have. As I said above, I believe that if an ACC admin can trust an ACC user to create accounts with no limit, they should also trust them to properly handle requests that tripped the antispoof extension and require a user with the account creator permissions to override and create (and vice versa). :-) ~Oshwah~(talk)(contribs) 16:42, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Oshwah: - I realise I agree with you, but to run with the Event-Coordinator compromise theory a bit further, it would be clearer cut - the damage possible is pretty tiny. Even if they made every account they created confirmed, it wouldn't cause a great uptick in carnage. Nosebagbear (talk) 22:36, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Oshwah: what is the expected amount of accounts to be created by "new" ACC volunteers per period? (i.e. would 6 or 8 be enough?) since the "rights they don't need" here to ECC users is expected to be way more than is needed by the relatively minuscule ACC team. — xaosfluxTalk 16:59, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I think we should have a bot or some kind of tool check for accounts which are hitting the account creation limit but do not hold the rights event coordinator, account creator and are also not ACC tool users. The account creation limit was lowered for a reason and increasing it without keeping a check in place would be a gross violation of WP:BEANS imo. Thoughts, @Nosebagbear, JJMC89, Xaosflux, and Oshwah:? --qedk (t 桜 c) 14:19, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
If this is a major issue, the report would have to be run quite frequently, and viewed frequently by patrolling users. Otherwise, this method might not be effective enough at stopping abuse and quickly enough... ~Oshwah~(talk)(contribs) 14:30, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
(edit conflict) QEDK - Doesn't sound like a bad idea to me. How would this new bot alert others that an account is hitting a limit and isn't within one of those groups? Who would this bot alert? Where? This is something that we should figure out if we're going to consider an idea like this... :-) ~Oshwah~(talk)(contribs) 14:29, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Functionally, a bot wouldn't be able to work "that way". Also, bot's wont be able to see "that you got denied by the limit" , but a bot could periodically generate a report of "accounts created per user over some time period" and could either filter out members of certain groups or just report the groups as well. — xaosfluxTalk 14:38, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Why not? The logic is pretty simple, you would need to check creation logs iterating a certain period (maybe an hour) and track accounts which create another account for 24 hours at minimum and more if they somehow meet the limit each day (hence, suspect). Wikipedia accounts which do not have a similarly authorized account in ACC (or the other account creation rights as well) have demonstrably no reason to carry out actions like this, hence red-flagging them almost immediately. --qedk (t 桜 c) 14:49, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
A bot could create a report, technically it won't be able to tell if you actually got stopped by the limit, just that you hit it or approached it. It wouldn't work "the way" of the protected edit requests in that those don't mine logs, they make use of what links here/category memberships. But the output could still be made. Have a bot periodically (say hourly) ingest the user account creation log and make a report. I think it may even be helpful to have it report on everyone, or everyone with say 3+ creations - and also to identify accounts made by coordinators, etc - so they can be coached as needed. — xaosfluxTalk 14:54, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Yeah, I mean, technically not. But I'm saying it like the logic is clear that an account cannot make more than 10, so an account which makes 10 accounts can be construed to have hit the limit, what's important is identifying if anyone is trying to make a large number of accounts in a short period of time, hitting the actual limit is more of a formality. --qedk (t 桜 c) 15:06, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Almost all ACC users in that 10+ range, minus the one event coordinator. Unfortunately I won't be appearing in that query anytime soon due to a certain rangeblock with "account creation disabled" set. Really puts a damper on ACC work... — AfroThundr (u · t · c) 01:51, 15 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Nosebagbear: Besides IPBE, I'm not aware of any (current) facility to exempt an individual user from the effects of a rangeblock, at least not the account creation part.
@Xaosflux: - thanks, suspect it was one of those merging of facts I got while swinging around the policy pages. Clearly, I'd made a terrible nerd Nosebagbear (talk)
@Xaosflux: Yep, definitely tracking that one, and if they do get around to implementing it, I would be first in line to request IPBE so I can get back to helping in ACC. — AfroThundr (u · t · c) 18:37, 15 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
The idea of granting (permanent) Event Co-ordinator rights to any ACC tool user who didn't possess Account Creator rights was mooted as a compromise. The right waives the account creation limit, and also allows accounts to be made confirmed. Obviously the latter isn't needed, but as I noted above, even if a tool-user went rogue, the maximum potential damage is significantly smaller (than the additional rights of Account Creator). It makes a good halfway house between nothing and Account Creator, and if Option 1 turns out to be inviable, then it might be the only way to significantly help with their task. Nosebagbear (talk) 18:46, 17 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Oppose The event co-ordinator right will allow the ACC team to grant confirmed right to new users. And the new users will start to create articles in the mainspace, which will cause more damage. Masum Reza📞 10:20, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
So, the prior "temporary" reduction has been lifted and the setting is back to 6 accounts per day for all projects; that being said is anything really needed now? I think that it is reasonable for volunteers working with the ACC team to get account creator access after a short warm-up/training period - and having the team communicate the plan to new members and getting those swiftly processed (say within a fortnight of actively working with ACC) is a good thing. — xaosfluxTalk 13:16, 25 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I haven't personally noticed any issues with ACC members requesting and getting the bit granted — after they have demonstrated continuous good judgment for a few weeks, that is. I still think it might make sense to raise the limit to 10 for enwiki, being the largest userbase, and with that query and edit filter from above, we can continue to monitor non-ACC users with high creation rates. — AfroThundr (u · t · c) 15:49, 25 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Comments: I am new to this, support account creation, and was appalled at the backlog. A note that 2-3 days may be needed, may take weeks or even months, and a backlog of 4 months seems to point to a possible loss of good editors at worse, those legitimately seeking an account to lose interest or maybe just not actively seeking an account. Maybe I am looking at this wrong but a backlog of 4 months seems to indicate "is anything really needed now?" a strange question. I understand the need to limit account creation abuse and possible vandalism, but if what is in place seems to be a horrible failure then why not an increase to maybe the 10 suggested instead of back to the statue-quo? I haven't looked at this, just read over some of the above, but has there been a problem with "trusted user" abuse to cause the decrease in the first place? Otr500 (talk) 08:55, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
The backlog doesn't have anything to do with the rate limit. Almost everyone working at ACC has noratelimit (from accountcreator or sysop), so the limit doesn't apply to them. The backlog is from a shortage of volunteers willing to devote time to working at ACC. — JJMC89 (T·C) 17:28, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
If it's back up to 6, then I don't think further changes are needed. New volunteers can get the accountcreator bit once they have a bit of experience. The biggest issue is number of volunteers. -- Ajraddatz (talk) 01:11, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
WP:ANI#Unknown attack on me contains some {{IPvandal}} links to individual IPv4s, individual IPv6s, and IPv6 ranges. Here are three of them, plus a totally unrelated IPv4 range:
You'll see that the template doesn't do well with some of the range code. Is there a way we could fix this, either by instructing the template to drop the "http" link if it's not a simple IP, or by otherwise rearranging something? Nyttend (talk) 20:13, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Seems that "Global User Contributions" (at => https://tools.wmflabs.org/guc/?by=date&user=Drbogdan , for instance) once gave truly "total contribution results", but now seems limited to "20 results per wiki"? - QUESTION: is there a way to again obtain truly "total contribution results" with this wiki tool (or some other related one) - and *Not* be so limited (to some number of results per wiki)? - in any case - Enjoy! :) Drbogdan (talk) 00:52, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Hello. @Drbogdan: the GUC tool was down at the beginning of June, then it has been repaired with Phabricator:T224930, with the limitation that you have seen. But in the Phabricator task, Krinkle said "I'm gonna land the patch now, although it only works for recent changes right now. Not for "All contributions". [...] I'll fix that in a separate change, but closing this for now." so I am convinced that, after the next fix, GUC will show again the "total contributions count" (for all projects) and the "project contributions count" (for each project). Regards --NicoScribe (talk) 21:59, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Drbogdan: The GUC tool has always limited the number of results from a single wiki to 20. This has been the case since the tool's creation by Luxo for Toolserver in 2014. However, there are two things that did change since 2014:
In May 2018 (last year), I added the text "20 results per wiki" so as to reduce confusion for users not aware of this previously (phab:T167524).
In June 2019 (last month), I switched the default grouping logic from "per wiki" to "per day" (chronological globally, instead of per-wiki). This has not made any change to which results are shown, merely in which way they are grouped. Both grouping options are still available as before, and can be selected in the form, or by url. This was requested by several users (phab:T193896).
As always, if you are interested in seeing more results from a specific wiki, use the "contribs" link next to the user name to continue for more results (which links to Special:Contributions on the relevant wiki).
Regarding the "global edit count" (as a number, not the list of actual edits), this can be better retrieved from Special:CentralAuth.
When writing my message above, I knew about "20 results shown per wiki". That's why I focused my message on something else: the "total contributions count" (for all projects) and the "project contributions count" (for each project). These 2 types of count are necessary (for me) to follow several long-term cross-wiki abusers. When you wrote "I'm gonna land the patch now, although it only works for recent changes right now. Not for "All contributions". [...] I'll fix that in a separate change, but closing this for now." in the Phabricator task, you were not talking about these 2 types of count?
CentralAuth is great for many uses but is unable to show the "project contributions count" and the list of recent edits side to side (for each project). GUC was able to do that, before. Moreover CentralAuth does not work for IP users.
@Drbogdan: CentralAuth considers the deleted edits and ignores the imported edits, whereas GUC ignores the deleted edits and considers the imported edits. For instance:
Special:CentralAuth/Drbogdan says that you have 6 edits on en.wikibooks.org, but b:Special:Contributions/Drbogdan lists 43 edits → 37 of your edits (done in other projects) have been imported here (and GUC shows your 20 recent edits, imported or not).
Special:CentralAuth/Drbogdan says that you have 31 edits on de.wikipedia.org, but de:Spezial:Beiträge/Drbogdan lists 987 edits → 956 of your edits (done in other projects) have been imported here (and GUC shows your 20 recent edits, imported or not).
In the mobile view, <small>..</small> has no effect on the size of the displayed font. This appears to be implemented in the different style sheets used in mobile view. I assume this was a deliberate design decision – perhaps it was thought that making already potentially small font on a mobile device even smaller wasn't a good idea.
Up until February 2018, {{small}} was a wrapper for <small>..</small>. It was then changed to be a wrapper for <span style="font-size:85%;">..</span>. This is obeyed in mobile view, so does generate smaller text.
When I'm looking to see what a user has been up to, looking at their contributions page is usually way to verbose, because it shows every edit. What I usually want is to just see the distinct pages. In pseudo-sql, I want something like, "select distinct page_name from contributions". Is such a thing possible, short of using Quarry?
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
For event organizers, if you request a temporary lift of the IP cap for mass account creation, this will now also raise the edit rate limit for those new accounts at the event, which will prevent another bottleneck. [10]
Administrators at all Wiktionary, Wikivoyage, and Wikisource wikis are now able to use the new partial blocks feature. [11]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 9 July. It will be on non-Wikipedia wikis and some Wikipedias from 10 July. It will be on all wikis from 11 July (calendar).
The design of MediaWiki's software windows will change for desktop users. Layout will be simpler, buttons will be bolder and clearer, and close buttons will be just icons. This is like the mobile design. This will affect ContentTranslation, VisualEditor, TemplateWizard, and other tools. [12]
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 10 July at 15:00 (UTC). See how to join.
Future changes
Wikidata will be in read-only mode on 30 July from 05:00 to 05:30 UTC because of a server switch. [13]
There will be a change in the name format of new Wikidata RDF dumps starting on 15 July. [14]
I'm not sure what the best venue is to ask this question, but I was at Wikipedia:Welcoming committee/members and in these edits, I purged a bunch of sock operators, some unregistered users, a bunch of redlinked users who hadn't edited in forever, and without looking at the rest of the list, I can only wonder how many people there are actually active. Is there any technical way to purge the list of duds? I also noticed there were tons of green-linked names, which typically represents users who have changed their handles.
@QEDK and MJL: I'll gladly install whatever anybody strongly recommends. Since the redirects already show up as green for me, I was trying to figure out what I already clicked in my prefs/gadgets/whatever, so if anybody has any idea, please let me know. Also, I'm still curious about purging the Welcoming committee members page, although it's a low priority on account of it being an indiscriminate user list. Cyphoidbomb (talk) 06:46, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@MJL: You are awesome. I can't keep track of the various common files and most of my changes have been to common.js, so I am much appreciative for your sleuthing. I come to the tech board so I don't have to walk in circles aimlessly like an asshole. Thanks, mate. Cyphoidbomb (talk) 06:57, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I was trying to log out one day but the step was slow. It said, "You are being logged out, please wait". Then it said, "Cannot log out now: http". Eventually I was logged out. Why so long? Does it mean that I must have been using a slow network? If I close my browser while waiting, is that good enough? Nick Levinson (talk) 20:26, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
You say 'one day' and you were eventually logged out, that means the issue may no longer be there. Have you tried logging out again to see if the issue persists up to now?. – Ammarpad (talk) 05:12, 7 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Preventing a logout is a security concern, thus I asked, even if it doesn't repeat for me. I agree the issue may be gone but it may not be, which is why I said "one day" and then posted. It did not recur on another day but that doesn't mean it was resolved. I think I had another well-known site open under my login during the same session; if so, I had no problem logging out from there. I assume the two strings I quoted (minus "http") can be searched for in MediaWiki software or the Wikipedia implementation to find what causes them to display, but I can't do those searches and I don't know how to test for recurrence of the problem, because if the cause was network slowness I don't know how to slow a network that I don't control and most networks I use are likely fairly robust.
Does the problem come from network slowness or something else? If anything was done to resolve it, that's different and please tell us.
What is the correct syntax to set the inline parameter conditionally in this template? It is embedded in the London Overground article thus: {{Overground RDT|inline=yes}}, which should be able to set the inline to 1 or true. The aim is to hide the top bar of the template when embedded in an infobox but not elsewhere.
I attempted this but it didn't work, so clearly I'm not getting the conditional syntax right:
{{Navbar-collapsible}} is a good utility (showing both V-T-E links and the Hide/Show button). Now IIRC, there was a similar template for (wiki)table headers. Cannot find it any more, did anything bad happen? If someone could give me a hint/link, +appreciated. -DePiep (talk) 20:37, 9 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I can successfully log into the web browser version of Wikipedia, but I cannot log into the Android app using the same credentials. I received a generic error that only states that an error has occurred.
I have also tried using the same automatic input of credentials from the same source and mechanism on the same device to control for my user error. Again, browser version login works, app no :(
@Luk: The same issue bugs me to no end. I'm not even using an Unicode username, which has been an issue in the past. All that I could think of was that either my password - 32 character sequence of random ASCII characters - somehow triggered the bug, or that the Pie autofill API weren't accepted. I wasn't using VPN either. There is only a very slim chance I could log into the Android App without problem. Is there an phabricator on this? Tsu*miki*⧸🌉 16:31, 10 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I just posted this in a section above, but moving it here. The last couple of days, I've been getting 500 - Internal Server Error Here is one from WP:AIV I've tried multiple times just now 1. Here is one from a different IP 2. — Maile (talk) 21:02, 10 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@GiantSnowman: The limit is there to prevent long-running queries that likely wouldn't finish, and would unnecessarily slow down XTools for everyone else. I can try increasing it a little bit, but we have to have some sort of sane limit. phab:T182182 is about analyzing the most recent 350,000 edits, but I suspect this wouldn't really help because in theory we'd still have to scan all of your contributions to get the most recent 350,000. The issue with Pages Created, specifically, is tracked at phab:T207959. One idea is to use the page creation log (phab:T221730), which is fast, but it would only produce pages you created going back to June 2018.
It's a tough problem to solve. We have to balance satisfying the needs of our users, such as yourself, while protecting stability and preventing unrealistic queries from being ran. This is compounded by more general issues with the replica databases, such as the inability to estimate how slow queries will be (phab:T188677) and more recently, general slowness following recent schema changes (phab:T226050). In the meantime, you could try using tools that don't have any limits (or the scalability problems that XTools has), such as Sigma's Pages created tool. Sorry for the inconvenience! — MusikAnimaltalk 16:19, 10 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I have increased the edit count limit to 400,000. It seems right now, the replicas are going fairly fast. Both Pages Created and Edit Counter didn't time out for your account. I can't promise it will stay that way, though. As an FYI, you can make the Edit Counter go faster by asking only for the data you need, using the checkboxes at https://xtools.wmflabs.org/ec. Best, — MusikAnimaltalk 16:27, 10 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Is there some facility within Wikipedia for me to receive a reminder when, for example, a block that I have made or a page protection that I have added has expired, or a deletion discussion that I have initiated has run its full time? Moreover, is there some facility within Wikipedia to create reminders generally? If not, can such a thing be created? bd2412T 22:52, 10 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
While this would be a godsend, e.g. for checking back on a talk page in 7 days or so, or allowing a 24-hour 3RR to expire, I am not sure it is MediaWiki's job to be tracking our reminders. That seems to present unnecessary load to the servers for something that individual editors would best be equipped to track locally. I have used Google Calendar and assorted alarm-clock apps to do this, so far. Elizium23 (talk) 23:06, 10 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Elizium23:, I don't know how big a server load this would necessarily represent. I already get all sorts of notices for things like being mentioned in a discussion or a link being made to a page I created. Obviously some system event is occurring when a block or a page protection expires, because the system knows to lift the block or unprotect the page. I suspect that implementing such a thing is much more a matter of prioritizing it than any effect on the servers. bd2412T 23:16, 10 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
A JS tool can be made to log certain temporary actions (and/or any kind of reminder you want) to an userspace subpage and serve you reminders based on that. Noting that, the JS datetime implementation is... almost nonsensical, at best. So, kudos to anyone who does. Alternatively, and this is easier, you can use Siri/Assistant, does seem like a better choice, but it'll mix your onwiki/offwiki life. --qedk (t 桜 c) 05:49, 12 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Is there a way (via template or lua) to extract the ToC headers so they can be presented in a different style? What I mean by that is using a ToC style such as {{Horizontal ToC}} but without the ridiculously awful need to manually write each header, and later update it if it's changed. --Gonnym (talk) 14:19, 10 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Yeah, I just found it by accident. There really is no reason to have the newer template. If a manual list of entries is somehow needed (and I really can't even see one valid reason why it would), that could added to the better template. --Gonnym (talk) 09:04, 12 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Icnis Mrsi: I'm not sure what you mean by edit form, but it's the nature of an edit conflict that you can't save. I can't save but my edit appears. Note that I just had a normal edit conflict with you and had to repost it in the upper text field as usual and save. Doug Wellertalk 17:41, 2 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
This has been happening to me too on Windows with Chrome browser. It is new behavior, but I also remember seeing it in the past. I can't see any pattern for when it will happen and when it won't. Last time I saw these behaviors, it quietly stopped happening on it's own. ~Kvng (talk) 15:44, 12 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I had this for a few weeks, thinking it was maybe some server issue that would solve itself. It didn't. Before destroying my computer I reset my settings in the preferences and it solved itself. It must be a conflict with one of those, but I have no idea which one. --Gonnym (talk) 15:57, 12 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
At File:Dave_Carlascio_and_Family_Force_5.jpg, some old revisions of the image give a 404 error message. Thumbnails of those revisions are still included by the HTML page, and it links to where the old revisions would have been. From the revision notes, it looks like they were non-free, so probably should be deleted, but, well, they weren't deleted.
By comparison, here is what old deleted revisions of a file look like: File:City_of_Spokane_Seal.svg — "No thumbnail" note, and no broken links or images. So, the problem with Dave_Carlascio_and_Family_Force_5.jpg appears to be a software bug, disk corruption, or similar.
Could someone properly delete the old versions in this case, and investigate the cause of this to ensure other files (that shouldn't have been deleted) aren't corrupted, restoring the revisions from backup as needed? Thanks! —{{u|Goldenshimmer}} (they/their)｜Talk｜Contributions 22:12, 13 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
My watchlist is again showing pages and diffs I have already seen, even though I have it set to show only unseen changes. Bolding of these pages in the list is also inconsistent. Anyone know why this exceptionally fun behaviour has returned? —Joeyconnick (talk) 22:50, 13 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Thanks Headbomb. Seems from this Phabricator discussion that no one knows what the problem is. It's been 3 weeks now, and I can't see that anyone has taken this on as their task - but perhaps I just don't understand how WMF technical people work. --Anthonyhcole (talk · contribs · email) 05:35, 9 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Citation bot noticed it a month ago. It was mistakenly thought to be a DNS firewall problem in the Phab ticket. I determined that it was an issue with data sizes exceeding 4K within DNS messages, then someone else determined it was only a problem with secure dns. In summary, there are all sorts of standards and extensions to DNS and pubmed sends something that we don’t handle. Side note: from what I read, handling split messages over 4K makes some attacks easier. AManWithNoPlan (talk) 12:57, 9 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
This is normal behaviour for templates: you cannot pass a Wikimarkup table through a parameter. I suggest that you make the documentation into a subpage, as is done with the majority of templates. If you state which template, I can carry out the appropriate edits. --Redrose64 🌹 (talk) 14:10, 14 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Well, is it possible then to make a subtemplate for inline documentation? Because I have got a following problem in the Ukrainian Wiki: few months ago I discovered that many templates there still contained old, Russian-style inline documentation translusions (Russians use their own documentation style, and there is a special template for inline documentation). So I replaced all those inline documentation transclusions with {{Documentation}} and the parameter |content=, but there were some cases with tables. Despite solving this problem by creating subpages, I think that it would still be helpful if a special inline documentation template is created. For example, in that link from a user's sandbox you can see a situation where it can be very useful to have such an option, as you don't need to create an extra docpage. That Russian template enables this option. --Gzhegozhtalk 15:03, 14 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Hi. I've just noticed that all article page titles are suddenly showing in italics. Must have happened in the last ~5 minutes or so. Do a null edit on a page to see, if it's not rendering in italics already. I take it this is some temp. glitch? Thanks. LugnutsFire Walk with Me 12:51, 13 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Gonnym: I saw this on many pages - in fact every article I looked at, for example, 1337x. In many cases it also displayed this error in red at the top of the page: "Warning: Display title "<i>1337x</i>" overrides earlier display title "1337x" (help)." -- zzuuzz(talk) 13:21, 13 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
See my latest ten contributions: some of the edits are tagged with PHP7, and others aren't, although I used the same browser on the same computer to make those edits, and all of them were done with my home wireless network. Any idea why three are tagged as PHP7 and seven aren't, instead of all ten being tagged or all ten not being tagged? The PHP7 page says Replacing the Beta Feature, since March 2019 a percentage of all production traffic has been randomly assigned to use PHP instead of HHVM. I would assume that this means that some of my sessions would use PHP7 and some wouldn't, but you can see that seven of those edits came in one session, yet exactly two of the seven edits used PHP7. Is every single edit randomly assigned or randomly not-assigned to use PHP7? Nyttend (talk) 21:10, 14 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
See Talk:Whist marker, for the views this trifling monograph has attracted over time - i.e. very few until suddenly 100,000 in one day! Do we have any ideas why this might happen? (I have seen previous hadwavey "bot" explanations, of similar phenomena, do we have anything concrete?)
Looking at the code, it seems that it skips watchers where the "updated since your last visit" indicator on the history page would show for revisions more than 180 days older that the most recent revision of the page. For example, if the most recent revision of a page is 1 April 2018, it'll skip any watchers who would see the marker on revisions from 3 October 2017 or earlier. Anomie⚔ 13:48, 11 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
The mobile visual editor is a simpler editing tool, for smartphones and tablets using the mobile site. The Editing team has recently launched two new features to improve the mobile visual editor:
The purpose is to help contributors focus on their edits.
The team studied this with an A/B test. This test showed that contributors who could use section editing were 1% more likely to publish the edits they started than people with only full-page editing.
The purpose is to smooth the transition between reading and editing.
Section editing and the new loading overlay are now available to everyone using the mobile visual editor.
New and active projects
This is a list of our most active projects. Watch these pages to learn about project updates and to share your input on new designs, prototypes and research findings.
Edit cards: This is a clearer way to add and edit links, citations, images, templates, etc. in articles. You can try this feature now. Go here to see how:📲Try Edit Cards.
Mobile toolbar refresh: This project will learn if contributors are more successful when the editing tools are easier to recognize.
Mobile visual editor availability: This A/B test asks: Are newer contributors more successful if they use the mobile visual editor? We are collaborating with 20 Wikipedias to answer this question.
Usability improvements: This project will make the mobile visual editor easier to use. The goal is to let contributors stay focused on editing and to feel more confident in the editing tools.
Looking ahead
Wikimania: Several members of the Editing Team will be attending Wikimania in August 2019. They will lead a session about mobile editing in the Community Growth space. Talk to them about how editing can be improved.
Talk Pages: In the coming months, the Editing Team will begin improving talk pages and communication on the wikis.
Learning more
The VisualEditor on mobile is a good place to learn more about the projects we are working on. The team wants to talk with you about anything related to editing. If you have something to say or ask, please leave a message at Talk:VisualEditor on mobile.
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
The mobile web will get more advanced editing tools. Seven more Wikipedias can use them now. This works for Arabic, Indonesian, Italian, Persian, Japanese, Spanish and Thai Wikipedia. You can try the tools on the mobile web and give feedback. [18]
Changes later this week
The abuse filter system user will soon do maintenance edits on broken abuse filters. This user is called Edit filter and has administrator rights. This is meant to fix technical problems. It will not do any other changes. You can read more.
The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 July. It will be on non-Wikipedia wikis and some Wikipedias from 17 July. It will be on all wikis from 18 July (calendar).
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 17 July at 15:00 (UTC). See how to join.
Future changes
The Wikipedia app for Android will invite users to add image captions to images on Commons. It will only invite users who have added a number of edits in the app without being reverted. This is to avoid spam and bad edits. You can read more and leave feedback. [19]
Some time ago, the save button was replaced with a "publish changes" button. I work with an awful lot of new editors both on-wiki and off-wiki, and it is perhaps the most frequent source of confusion (after maybe why VE doesn't work on talk pages -- but that's a whole other deal with technical constraints). The awkward language choice of part of the interface shouldn't be something I have to bring up in every introduction to editing session I run (and shouldn't be something that confuses so many people even after bringing it up). Specifically, it comes up when new users are starting to edit in their userspace, in a sandbox, in a draft, etc. -- people see "publish changes" and hesitate because of the implications of "publish".
IIRC this change was made by WMF legal and is non-negotiable; they wanted to make it clear to editors that the moment one clicks that button, whatever is in your edit window becomes publicly available for anyone to view and not saved to a private userspace inaccessable to others, whatever the namespace being edited. It was a global change, so the discussions will I assume be on Meta. The announcement was here, so the discussions if there were any will be shortly before that. ‑ Iridescent 17:49, 11 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Actually the save button was changed to "publish changes" because of newbies. In UX testing newbies did expect the save button to work more like drafts. There was a need to change the text of the button to be more decisive. The bug behind this change is T131132, which explains this further.--Snaevar (talk) 19:32, 11 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Thanks all. From the sound of it, it seems like it makes most sense to use "publish changes" in most namespaces, but switch back to "save changes" for draft and userspace? Might be too much of a hassle to change, though (other than on a per-user basis with a script, of course, but that sort of defeats the point). — Rhododendritestalk \\ 16:32, 12 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Rhododendrites, I've been asking around about this since the change was made a few years back. So far, with one exception, the editathon folks tell me that the problem is that new users actually do understand this, and are intimidated by making their creations available to the general public. They want to clean it up and try to make it "perfect" before anyone else can see it. (That is, they're looking for a save button that doesn't publish their edits, which is not how our big blue button works.) I'd be very interested in hearing whether your users express similar sentiments.
OK, if there was such a hoo-hah about calling it "Save" then why does the ephemeral popup dialog still read "Your edit was saved." Should it not be changed to "Your edit was published!" for consistency? Won't someone be confused about whether the edit was saved or published, when she pressed "Publish" but it was "Saved" instead? Also, the ephemeral dialog is annoying to me: it covers screen real-estate, can't be dismissed early, and goes away without being acknowledged, as if we had time to spot and read it. Not a good experience at all. (EDIT: It apparently can be dismissed early, if your reaction time is FPS-trained enough to hit the tiny "X" before it fades and disappears (~5 seconds.) Elizium23 (talk) 14:03, 13 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Redrose64 and Whatamidoing (WMF): I've not found it an issue for new editors at editathons and workshops. I almost always guide new editors through their first edit, which is normally to their user page to say what topics they are interested in. I make a point of explaining that publishing it makes it visible to the whole world and caution against writing anything that they wouldn't want everyone to see. After that I use "publish" and "save" interchangeably and I don't believe I've ever found anyone confused by that. Hope that helps. --RexxS (talk) 15:08, 16 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I do not think those templates should be used to warn "IP addresses" as they're not meant for that. Paid editing is done with accounts that's why the disclosure is needed on userpages. If an IP address is persistently making promotional or suspicious editing, they should be reported to the appropriate noticeboard not be asked to disclose their client on their "IP userpage" which does not make sense. – Ammarpad (talk) 18:36, 17 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Hi. In our Colossus of Rhodes article is a timeline/map of the 7 wonders, which inadvertently implies that there were 8 of them (by referring to the Colossus "and the other 7" wonders).
Hi PrimeHunter, Apologies for confusing editors with the extension. I think having it is useful as it informs editors that, unlike other templates, it's purely an image thumbnail. Furthermore, it gives the image type (extension). Finally, the exact filename of the image is there, should anyone want to go directly to the image page. Thanks for helping out Dweller, regardless. cmɢʟee⎆τaʟκ 17:07, 18 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
When a user drafts content with references in a sandbox, if using the Visual Editor it is necessary to enter edit mode before copying in order to retain the references. If the user doesn't copy from edit mode, the superscript links will be retained, but they will be links back to the original page (where the footnote anchor would be) without the reference itself. You can see an example of this in my sandbox:
This sandbox shows the first paragraph from the body of Wikipedia copied from edit mode.
This sandbox shows the same paragraph copied without entering edit mode.
It would be useful to have an edit filter or some other way to indicate when this happens. This is something I always tell new users, but which people very regularly forget about, just to introduce improperly formatted content into an article when trying to copy out of a sandbox. It seems like this could be easily detected by looking for superscript tags around a link to a different page. (Another common sign this happened is that "[edit]" appears inside a heading). Ideally, this would notify the user when they try to save, but an edit filter could be useful, too. — Rhododendritestalk \\ 18:25, 17 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Beland (talk·contribs) has been replacing HTML character references with the actual characters they represent, using JWB. Is there a consensus or justification for this?
The replacements are concerning to me especially given they include characters in Private Use Areas, which IMHO are best left as references (frankly I don't think they should ever be used in articles in the first place, but still). And even if it was justified, wouldn't it fall under WP:COSMETICBOT? Nardog (talk) 21:50, 18 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Greetings! I was actually wondering whether I should be keeping Private Use Area HTML entities as they are. In my browser, I can see the Unicode point number of characters I don't have fonts for, but I'm not sure about other editors. This began as part of a spell checking and Manual of Style compliance project. I'm trying to bundle HTML entity cleanup with any punctuation cleanup on the same articles, so there aren't a bunch of minor commits. Right now I'm working on a list of only about 5,000 articles; in some cases, the HTML entities represent breakage so there's reader-visible cleanup to do, but you're right it's often only editor-visible. I've been getting occasional thanks for the entity cleanup, though; where done right it makes the wikitext a lot more readable, especially to editors who don't know HTML. (For example, café is a lot easier to read and edit than cafÉ.) I had a conversation with some MOS editors before starting this, and there was a strong consensus in favor of converting numeric HTML entities where possible, unless the result would be confusing, and I made a list of confusing situations to exclude. Unfortunately, Unicode is a huge place and no one thought about potential problems with combining characters (I'm leaving those alone after editors on some Arabic-langugage-related pages rightfully complained) or the private use area or a handful of other things where I'm trying to building bottom-up consensus. I'm leaning toward PUA characters being too confusing to convert, so I'll add them to my exclusion list unless someone here would much rather see real characters than numeric entities? Ah, I see Template:PUA actually says not to convert them; that's also a page that will probably give a comprehensive list of articles they are used in, if anyone wants to go around pruning any unnecessary ones. -- Beland (talk) 23:14, 18 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Greetings, I just discovered that an edit to a page I have watchlisted (Special:Diff/906832193) is apparently a phantom, as it did not appear on my watchlist and the ping did not trigger a notification. I already checked that the ping was done correctly, my preferences enable me to be notified by said ping, and that the page is indeed on my watchlist. Also, my watchlist has updates later than this edit, and I got notifications as recently as yesterday and have not knowingly changed any settings since. None of this explains the conspicuous absence of this edit from both my watchlist and notifications.
For the watchlist, I believe it is the same issue that was resolved earlier in January at phab:T211849, but I believe it still occur sporadically. I've experienced that some weeks ago but didn't have time to report the issue. You can report it again. For the ping, I am not sure why it didn't work. – Ammarpad (talk) 05:05, 19 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Vchimpanzee: from some testing, it looks like their website is just having an intermittent outage right now (got it on the 'new link' as well) - in any case I updated the offical website property on wikidata and set the template to use the WD value. — xaosfluxTalk 17:16, 13 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Vchimpanzee: you are not seeing a Wikipedia issue, you are seeing an issue with their web pages. To test I typed the URL in to a broswer, then opened and closed it 5 times, it failed three times. This is occuring for both the 'dearabby.com' link, and the 'uxpress.com' link. There is nothing we can do to fix their broken website. — xaosfluxTalk 18:30, 15 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Vchimpanzee: I don't think you understand the technical problem - it isn't a problem with one of those domain names vs the other, it is a problem with the connection between the second domain name and the actual web server - as confirmed by the server owners in your response above. We've demonstrated that this happens with both URL's. This is not a problem with the English Wikipedia or with the mediawiki software in general. There is literally nothing else for us to do here. — xaosfluxTalk 17:52, 20 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Sometimes website are broken and there is nothing to do but wait and hope. We could try to change all URLs to the redirect and/or adding archive links for non-working links. But since they said they are working on it, we should wait. -- GreenC 18:07, 20 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
If the only problem were with the websites first 'redirect' page, then yet it would be fine to just bypass this - but please see above - the problem is not with the first link, it is with where they redirect it to. — xaosfluxTalk 17:37, 21 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
Communities interested by easing newcomers' first steps can now benefit from the Growth team experiments on their wikis. Check the conditions and the request process.
The Coolest Tool Award 2019 is looking for nominations. You can recommend tools by July 29. The awarded tools will be presented at Wikimania. [21]
Problems
The release of the last version of MediaWiki (1.34.0-wmf.14) has been blocked for groups 1 and 2. [22]
Changes later this week
Phabricator database will be moved to a different server. Writes will be blocked on Thursday 25 July, between 05:30 and 06:00 AM UTC. Reads will remain unaffected. [23]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 23 July. It will be on non-Wikipedia wikis and some Wikipedias from 24 July. It will be on all wikis from 25 July (calendar).
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 24 July at 15:00 (UTC). See how to join.
Future changes
Some items in the visual editor will change later this week. This will make it easier to edit links, citations, and templates on both desktop and mobile. [24][25]
With advanced search turned on you will be able to choose the sorting order of the search results when you do a search. [26][27]
I have recently become confused by some transclusions on sports seasons articles such as 2019–20 UEFA Europa League, which under the "third qualifying round" header just has the following code to produce the fixtures table, with no edit button as is usual on templates:
{{#lst:2019–20 UEFA Europa League qualifying phase and play-off round|Q3}}
I cannot find the corresponding template or module for this anywhere, can anyone give me a hand?
Is there a better way? I've used it to transclude chunks of appropriate help text from Help:CS1 errors into the various error category pages in Category:CS1 errors. It's worked well for that. One source page so only one page to maintain. But if there's a better way, ...
The real solution for tables will always be 1 data source, that you call from whatever page you are on and get the results placed into the table. That was supposed to be Wikidata but it seems that won't happen. Anything else is just a backwards way of trying to handle tabular data. See any TV award, which is written and independently sourced in the TV article, season article, actor article, the TV award itself and if the character that actor played has an article, that article as well. /off-topic rant --Gonnym (talk) 15:15, 22 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Oh, aye? But don't we, at en.wiki, proscribe article text in template space? Not my creation but the documentation for the cs1|2 templates is primarily handled by Template:Citation Style documentation and a plethora of sub-templates. It is a pain to maintain and that, in my mind, disqualifies it as a 'better way' than labeled section transclusion. So no 'better way' than templates?
It's not, but the OP provided an example where labeled-section-transclusion is used in article text which avoids the no-article-text-in-template-space proscription. My csdoc example is intended to show that were article text allowed in template space, such use of templates can be unwieldy. So am I to understand that while you consider labeled-section-transclusion to be an abomination, you don't have a better solution?
I noticed today that when you click on a reference which is a bare URL in Visual Editor, the edit box has a bottom section that says, This reference consists of just an external link. You can use the "Convert" button below to generate a properly formatted reference. Is this new, or have I just never noticed it before? -- RoySmith(talk) 22:54, 19 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Interesting, but weird that I've never noticed it before. Has something changed to make it more obvious? My usual process has been to copy the URL, create a new Automatic citation, then delete the old reference. It's just odd that I've never noticed the Convert button before, which does all that with so much less effort. -- RoySmith(talk) 16:45, 22 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
As I noted at the end of June, through the summer we will be running systems tests in preparation for the end of year fundraiser on the English Wikipedia.
This weeks test is scheduled for 1500 UTC Wednesday 17 July.
Hello. On my talk page Mnnlaxer asked about a situation with the collapsed tables at the Israel men's national lacrosse team article. Because they are blue readers can't see the "show/hide" command. I think I've seen tables where they are highlighted in white but I have no idea how to make the change. Any help that can be provided will be appreciated. MarnetteD|Talk 18:41, 24 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
{{hidden begin}} can replace | bodystyle = background:#FFFFE6; with | style = color:white; | bodystyle = background:#FFFFE6; color:black; as the below example. The style parameter also applies to the collapsed text so it's returned to black with bodystyle. I don't know whether this can cause issues for some users trying to replace normal black text with another color for themselves. The gadget "Use a black background with green text" appears to work as normal. PrimeHunter (talk) 09:24, 25 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Hi, i am Monniasza, and I have found bug in "Allow navigation menus to be collapsed" gadget.
It causes sidebar to get malformed by icorrectly indenting its contents.
mobileUndo script is an userscript created for mobile. It basically adds a button to revert the latest revision of an article while previewing a diff on the mobile website. Currently there isn't any undo feature in mobile version of the mediawiki software (as far as I know). It meets the general criteria for gadgets and I have the original creator's permission. Therefore I am proposing this script to be approved as a gadget. Should we approve of this script as a gadget? Masum Reza📞 12:01, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
My statement – I am a regular user of this script and have been using it since January, 2019. I can assure you that it possesses no threat to sensitive data of it's user. This is a very useful script for both editing and counter-vandalism. Making it a gadget will benefit many users editing on on mobile devices.
Questions
A list of questions and answers I believe would be useful.
1 Does it work if just included with no further configuration?
Yes. It works with no further configuration.
2 Is it configurable via personal common.js?
No. The current maintainer and the original script creator can provide more information.
3 Is it compatible with all major browsers in other words, cross-browser compatibility?
Yes. It is compatible with most major browsers on mobile except Opera mini. So far I've tested it's compatibility myself with Mozilla Firefox, Chrome, Chromium and Microsoft Edge.
4 Does it have any duplicates?
No, not on en-wiki except the current maintainer's copy. I've copied the script to my userspace on test wiki and meta wiki for performing tests. I am willing to delete those copies if necessary.
5 Does it require any special permission?
No. It even works with very new accounts. But I think we should not give its access to non-autoconfirmed editors to prevent misuse.
6 Which skins are compatible with this script?
Minerva Neue obviously as this is the only skin available on the mobile website.
7 Does it have cross-wiki compatibility?
Yes it has. I've tested this script myself on meta, Japanese Wikipedia, Wikidata and test wiki. It even generates edit summary in other languages on other wikis.
It's now worse, in that nothing is now displayed other than the link. You need a timestamp (if not a full signature) after the statement so that Legobot knows where to stop parsing: WP:RFCST does state "Failing to provide a time and date will cause Legobot to remove your discussion from the pages that notify interested editors of RfCs." and that is precisely what has happened here. At the moment, the first timestamp that it encounters is the one at the start of this "Discussion" subthread, by which time the statement is no longer neutral and certainly not brief. --Redrose64 🌹 (talk) 13:33, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I'm a bit baffled by your second sentence. By nature of this being an addition, the onus is on the supporters to explain why it should be added. However, in discussions like these, explanations from both sides would be useful to all. Killiondude (talk) 19:53, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Instead we should ask the Foundation to Undo their removal of Undo from mobile. Creating a gadget to put Undo back is pretty absurd, unless it is the only way to get this fixed. I don't use mobile, and while I know the Foundation has badly crippled basic functionality on mobile I had no idea that they removed the undo link. That's pretty bad. If/when there's a clear majority here to ask the Foundation to fix this, give me a ping and I'll be happy to open a phabricator task and push for action. Alsee (talk) 13:27, 7 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Weak support (invited by the bot) I favor simplicity vs. trimming seconds off of the "revert" time, but it looks like its inclusion is optional, and that lots of good work has been done. North8000 (talk) 13:04, 10 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
The main page counter uses {{NUMBEROFARTICLES}} which says 5,957,430 when this is rendered. It is updated several times daily. Samsara's link does not claim over 6 million. The vertical axis has no number at the top. It shows a small horizontal line when the axis ends but this is not at 6 million. It is around 5.9 million. Hovering over the right side of the graph says 2019-06-01 Content 5.884.993 for me. PrimeHunter (talk) 10:13, 28 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I agree but it's not something we can change here. The horizontal axis has the same issue. There is a mark at the end but it's not at 2020. In that case it's currently easier to see that the last interval is shorter than between the other marks. PrimeHunter (talk) 12:21, 28 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
FWIW - perhaps to keep track of the number of Articles (and more) - is the following template => {{User:Dbogdan/WikipediaOverview}} - hope this helps in some way - if otherwise - *entirely* ok with me to rv/rm/mv/ce the template of course - in any case - Enjoy! :) Drbogdan (talk) 12:41, 28 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
QUESTION: Is there some code that can access a template residing on the English Wikipedia - from another Wikipedia like, for example, the Simple Wikipedia? More specifically, the template {{ScienceNews}} resides on the English Wikipedia - Question: Can this {{ScienceNews}} template be accessed from the Simple Wikipedia (without recreating/duplicating the template on the Simple Wikipedia)? If so, what code may be used? - tia - Enjoy! :) Drbogdan (talk) 16:01, 28 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Drbogdan, Interwiki templates are not currently supported on WMF wikis, mostly for performance and usability reasons. There's been some interest in developing the software to do this well for a long time (including in the 2015 Community Wishlist Survey where it was a top-10 wish), but nothing has developed out of it. --AntiCompositeNumber (talk) 16:18, 28 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Problem: For some reason, I'm unable to edit my watchlist (via "View and edit watchlist" or "Edit raw watchlist" in https://en.wikipedia.org/wiki/Special:EditWatchlist ) - even after restoring all default settings in my "Preferences" - and regardless of the browser used (latest versions of "Brave"; "Chrome"; "Firefox" used; Windows10/1903; Dell-XPS 8900) - seems earlier, all was *completely* ok with editing the watchlist - but now the listing in my watchlist (in edit mode) seems to appear very, very briefly - and then disappears? - any help with this would be appreciated - in any case - Enjoy! :) Drbogdan (talk) 15:16, 27 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Drbogdan: while there isn't a limit (well there probably is some super giant limit but you're not at it) WL's tend to get wonky over 5000 entries, so I really suggest you trim it if possible. Perhaps you have a bunch of old User:IPADDRESS ones from old feedback/warnings that you can remove. Also the safemode link disables scripts, such as the ones you have enabled in User:Drbogdan/common.js and User:Drbogdan/vector.js - you could try turning these user scripts off to see if there are any conflicts being caused. — xaosfluxTalk 16:43, 27 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Xaosflux: Thanks for your reply - it's appreciated - yes - trimmed some entries in "safemode" - but this did not work - remmed script in User:Drbogdan/common.js - as follows => <!---mw.loader.load('//meta.wikimedia.org/w/index.php?title=User:Hedonil/XTools/XTools.js&action=raw&ctype=text/javascript');
importScript('User:SD0001/oldSearchHistory.js');---> - not clear if this script is important for anything I'd miss at the moment - but yes - this worked *very well* and the WatchList edit seems to be *entirely* ok (in regular "normalmode") at the moment - Thanks again for your help with this - and - Enjoy! :) 17:17, 27 July 2019 (UTC)
@Drbogdan: .js pages use a slightly different comment code (I edited YOUR page with the right comment type - feel free to revert or do anything you want with it now) You can try turning those lines on back one at a time if you want them, then contact whomever's script you are loading if you would like them to work on it. — xaosfluxTalk 17:21, 27 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Xaosflux: - BRIEF Followup - after several tests - seems the particular problem script line in the "User:Drbogdan/common.js" file is => /*importScript('User:SD0001/oldSearchHistory.js');*/ - the other script line seems ok - and somewhat useful at the moment - hope this helps in some way - in any regards - Thanks again - and - Enjoy! :) Drbogdan (talk) 17:51, 27 July 2019 (UTC) [NOTE: corrected code - Drbogdan (talk) 21:12, 27 July 2019 (UTC)](discussiontools-replybutton)[(discussiontools-replylink)]
When I point my cursor at a link, as well as the usual popup preview thingy, I also get a little white box appearing above the link. I think it started in the last hour or so. Is this a new feature? It doesn't appear to do anything useful, or indeed at all. DuncanHill (talk) 23:01, 28 July 2019 (UTC)
Sorry should have said, monobook, Edge, Win10. DuncanHill (talk) 23:01, 28 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I'm looking for a template to produce the pagename of a template on both template's main page and template's doc subpage? That is, a template equivalent to following code:
Not a Wikipedia problem, as it occurs even when Wikipedia is not involved, but affects a lot of articles so it's worth raising here. Maybe somebody knows something about this, and in any case editors need awareness of the problem.
For an example of an actual affected article, see 2014 Isla Vista killings. Google Maps takes you to Isla Vista but displays the error and fails to place a marker. Appending one zero to the end of either lat or long fixes it.At this link is a place to report errors in Google Maps, but it requires a Google sign in. I don't have a Google account and I don't care to create one for this purpose. Perhaps someone else could report this error and return any feedback here.If we can't get this error fixed soon, we should start thinking about a change to the software we control to work around it. Accepting this for the indefinite term is out of the question in my opinion. ―Mandruss☎ 12:20, 29 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I used this template correctly, but it doesn't work. Look at my signature, it contains afromentioned template. MonniaszatalkInitial visibility: currently defaults to autocollapse
To set this template's initial visibility, the |state=parameter may be used:
|state=collapsed: {{Village pump (technical)|state=collapsed}} to show the template collapsed, i.e., hidden apart from its title bar
|state=expanded: {{Village pump (technical)|state=expanded}} to show the template expanded, i.e., fully visible
shows the template collapsed to the title bar if there is a {{navbar}}, a {{sidebar}}, or some other table on the page with the collapsible attribute
shows the template in its expanded state if there are no other collapsible items on the page
If the |state= parameter in the template on this page is not set, the template's initial visibility is taken from the |default= parameter in the Collapsible option template. For the template on this page, that currently evaluates to autocollapse. 10:25, 29 July 2019 (UTC)
{{Collapsible option}} is designed to be used on template documentation pages. It outputs text that describes how the state parameter works in those other templates. It doesn't do any collapsing itself. And, as Andrybak said, you may not use any template in your signature. -- John of Reading (talk) 10:43, 29 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Problems
Wikidata will be in read-only mode on 30 July from 05:00 to 05:30 UTC because of a server switch. [28]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 30 July. It will be on non-Wikipedia wikis and some Wikipedias from 31 July. It will be on all wikis from 1 August (calendar).
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 31 July at 15:00 (UTC). See how to join.
Thanks - I'll point Oddbodz to that. Is it generally considered acceptable to apply the fix on pages where I see it causing problems? I don't like to edit another chap's signature, but I like not being able to read all the following comments even less. DuncanHill (talk) 15:49, 30 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@DuncanHill and Pppery: if that is coming from a signature, that isn't a good fix, since you wont be able to insert that closing font tag after the timestamp in a signature. That last font tag needs to be completely removed, and the others should be closed as a quick fix, see User:Xaosflux/sandbox75 - really font is deprecated and there are much better fixes if this person is still editing. — xaosfluxTalk 15:52, 30 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
DuncanHill, there are some bots that can fix this if it is on a lot of pages, you can ask at WP:BOTREQ. In general if you see one fix it, unless it is on a user_talk page you are other wise editing (as it will cause "new message" flag for the page owner). — xaosfluxTalk 15:53, 30 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
A search [29] finds around 740 cases. This is a job for a bot or AWB. It's always OK to close open tags in signatures. I would also merge the nested font tags to get Oddbodz - (Talk) (Contribs). If deprecated font tags stop working later then it's no big loss if old signatures are rendered as normal text. PrimeHunter (talk) 16:12, 30 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Thanks all - I don't know how to explain things in bot request terms. I mean, I could tell them what I told you here, but I wouldn't understand what I was on about if I tried to explain how your fix works or how it would be applied. DuncanHill (talk) 16:15, 30 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
"Discovered" at Wikipedia talk:Principle of Some Astonishment#Random thing I noticed when somebody accidentally "nested" italic marks. The "nesting" obviously doesn't work, and is an error, because the italics are effectively 'closed' before the link text and 'opened' again after it, so you don't get italic text, but check out the funky "extra" link mark which gets added on the left of the link text...
''[https://www.google.com ''normal text'']'' = normal text
These "variants" also produce similar "results":
'''[https://www.google.com '''''italic text''''']''' = italic text
''[https://www.google.com '''''bold text''''']'' = bold text
''[https://www.google.com ''normal text'']'' produces the html <i><a rel="nofollow" class="external text" href="https://www.google.com"></a></i><a rel="nofollow" class="external text" href="https://www.google.com">normal text<i></i></a>. The link is split in two links to the same target. The first arrow belongs to the first link which has no link text. PrimeHunter (talk) 14:48, 30 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Yeah, I'd looked at the html source and seen that. It's an oddity that this "error" produces a double-link like that, as I said at the talk page it's something I've never seen happen before in 10 years, but an odd "bug" nonetheless... Looks as though the wikitext 'parser' is somehow seeing both <i>...</i> 'portions' as separate 'entities' that each need linking, yet using the single href target address... --Begoon 22:22, 30 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
The wikitext parser produces misnested HTML: <i><a rel="nofollow" class="external text" href="https://www.google.com"></i>normal text<i></a>. HTML5 specifies that that "tag soup" be corrected in a manner that produces the empty link, and thus that's what RemexHtml does. Firefox 68 does the same if given that misnested HTML, BTW, and other modern browsers should as well.
Parsoid, on the other hand, seems to interpret that wikitext to produce <i><a rel="mw:ExtLink" href="https://www.google.com" class="external text"><i>normal text</i></a></i>, i.e. it doesn't recognize "misnested" apostrophe markup and link markup in the first place. Anomie⚔ 13:31, 31 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Do we have a template/magic word combination that can achieve the following? I would like Portal:Germany to display Portal:Germany/Germany news whenever that page has been recently edited, and not display it when it is too embarrassing (say, when the last edit is more than a month ago). Is there some easy way to achieve this? —Kusma (t·c) 10:01, 31 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Kusma: keep in mind, that dynamic page content is not guaranteed, especially for non-logged in users; rendered pages are cached and simply viewing the page as a reader does not force re-evaluation of templates. — xaosfluxTalk 13:28, 31 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
That's okay, the worst things that can happen here are that the portal wrongly doesn't display a refreshed "news" section or displays an outdated one that I would rather hide. Neither causes any serious problems. But it is a good point that we shouldn't rely on re-evaluation of templates/magic words for anything critical. —Kusma (t·c) 14:08, 31 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
What's the fastest way to see if there's an existing wikidata entry for an article? What I do now is open another window, navigate to wikidata.org, and copy-paste the article title into the search box. Surely there's a more streamlined (one-click?) way to do this? -- RoySmith(talk) 14:43, 30 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
mw.loader.using(['mediawiki.util'],function(){mw.util.addPortletLink('p-tb','//www.wikidata.org/wiki/Special:Search?search='+encodeURIComponent(wgPageName),'Wikidata search','t-wikidatasearch','Search the page name in Wikidata',null,'#t-wikibase');});
I know the link. I may have misunderstood the question. I thought it was about an easy way to search for a possible Wikidata entry to add the article to if it doesn't already have one. PrimeHunter (talk) 19:45, 31 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
MA, yes, I think the question is whether an (other) item exist covering the same topic as an article, not whether the article is connected to a Wikidata item. --Izno (talk) 22:02, 31 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Thanks, and sorry for the noise. I read "existing wikidata entry for an article" as being a connected one. Furthermore many people don't even know about the links under Tools, so I wanted to make sure that didn't go unnoticed. — MusikAnimaltalk 15:08, 1 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Wait, that's a hidden text-only change, so how could that possibly be the cause? But what else has changed, that would break dozens of older versions of the article, that were definitely not broken this morning? Here's version 861002525 from 500 edits ago; just as broken. I can't understand what's happened, here. Mathglot (talk) 09:03, 1 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Thanks, Nardog, for the fix! (Apologies to Paine; not only weren't they the cause of the problem, but that edit was (nearly exactly!) a year ago. I was too tired and in too much of a hurry to see clearly.) Mathglot (talk) 17:41, 1 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
As I said I am using the mobile version of Wikipedia. I tried that too. I changed to desktop version clicked on the red button and the blue button. The blue button shows me old notifications like "user thank you" or something like that. Both the blue and the red button shows old notifications.--SharabSalam (talk) 22:04, 22 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
No, I'm talking about the blue circle at the upper right of each notification. It toggles the read/unread status of the notification. If there's no blue circle and only empty circles then click on them a few times. Nardog (talk) 22:10, 22 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I had no idea about the blue circle. I had never clicked on it since I joined Wikipedia. I have lots of notifications that I didn't click on their blue circle but I haven't got an issue like this before. It's gonna take a while to make all the circles empty? Is that what I should do? Make the circles empty or blue? Thank you for this information about the blue circle. I had no idea about it.--SharabSalam (talk) 22:17, 22 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I did that in past I was hoping it will remove the "+99" number from the notification button but when I did that, only 20 notifications become read and I just didnt see them getting removed or changed hence I wasn't aware of the blue and empty circle thing. So I didn't repeat the process. --SharabSalam (talk) 22:44, 22 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Nardog and Xaosflux: SharabSalam is correct, the behaviour has changed. As you know, if you got an alert notification (or thanks notification), the counter appears on a red (or blue) background. If you click that number, it changes to grey and the list of notifications appears. Let's assume that you don't do anything with those, but click away; the list disappears. Now follow a link (any link). At this point, the change in behaviour becomes apparent: the old behaviour was that the counter remained grey until the next notification came in; the new behaviour is that the counter becomes red (or blue) implying that you have new unseen notifications. --Redrose64 🌹 (talk) 22:54, 22 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Also reproducible on the mobile web. The notification icon changes from red to gray when I click on it but not mark the new notification as read and close the panel, but it becomes red again if I refresh the page. Nardog (talk) 23:57, 22 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I am seeing my blue "Notices" light on my desktop (Safari, iMac, OS 10.11) stay lit for a "Thank You" given 3 hours ago. My red "Alerts" light is off (i.e. gray); I received the last of those 5 days ago. Dhtwiki (talk) 23:49, 22 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Now I'm getting the red light on when I refresh the page. It turns off when I click on it to see the alert, but then turns on again when I reload the page. I'm using standard, "vector" skin, IIRC; nothing fancy. Dhtwiki (talk) 23:53, 22 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
That is also what I was explaining. I also noticed that now when I ping a random user who doesnt exist I don't get a notification saying something like "the ping was not sent because the user doesn't exist"--SharabSalam (talk) 01:01, 23 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Just so people know, AFAIK SharabSalam here is saying that the notification for a failed mention is working for them now. The problem with the notifications as a whole (the grayed number turning red/blue again) still persists. Nardog (talk) 11:39, 23 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Could you recheck the photos that you added to explain the problem. The "expected" after clicking on the notification button and refreshing is that the number disappear and the gray bell icon appears but what happens right now is that the notification appears again as if I haven't clicked on the notification button.--SharabSalam (talk) 15:02, 23 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
┌────────────────────────────┘@SharabSalam: I'm certain at least on the desktop site opening and closing the alerts panel without marking all alerts as read would have made the background of the unread count gray but didn't make the count disappear entirely. I don't know about the mobile site, though. Nardog (talk) 12:07, 24 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Nardog, It is the same in desktop. When you click on the notification button with the number it changes to gray which is as usual and the normal behaviour the problem appears when you refresh the page, what is expected is that the bell icon appears like if there was no notification but what happens is that the notification appears again. The photos that you added suggest a different problem. The expected photos should not contain the number of notifications in gray but the bell icon.--SharabSalam (talk) 12:31, 24 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
By the way, I am unable to enter or see that site ([30]) through my IP address I get this message all the time
Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator at webmaster@wikimedia.org to inform them of the time this error occurred, and the actions you performed just before this error. More information about this error may be available in the server error log.
The notifications/buttons are remaining red and blue for me as well. They go away for a moment when clicked on and then come back. Marking all as "read" doesn't solve the issue. I'm using a laptop. Flyer22 Reborn (talk) 16:31, 24 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Flyer22 Reborn, from my experience, I clicked on "mark all as read" and then I closed the notification window and clicked on it again and marked all as read again.. I repeated this until the number in the notification button became zero then the notification disappeared.--SharabSalam (talk) 18:38, 24 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Flyer22 Reborn: Sorry, that's not my area. I usually work with a desktop browser with scripting disabled—I much prefer Wikipedia that way (except when I need to run some JavaScript). I find notifications to be a PITA with scripting enabled but have no idea whether more experience with that would help. Johnuniq (talk) 00:55, 25 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Me three - Same problem here. The alerts and notices buttons stay "active" constantly. Clicking on them clears the "active" status but it comes back next time I go to any other page. JIP | Talk 10:16, 26 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Hi all Bbb23, Vanjagenije and myself are somewhat frustrated because the strikethrough blocked editors gadget/script is apparently not working with external links to user pages. At SPI this isn't great because {{checkuser}} uses external links to avoid pinging the users in question. Is there a solution to his? TonyBallioni (talk) 20:05, 2 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
What is the precise bug? As far as I see, iff the user-pages are red-links, they are displayed in blue and not stricken but the t/p-and-contribution links are stricken, as usual. (Bravanello over this SPI.) Otherwise, (i.e. if the user-page exists), all the three links are indeed stricken. (MDPMHG over this SPI.) Am I correct? ∯WBGconverse 20:51, 2 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I don't really agree about MDPMHG - it is not stricken in the first instance, which uses the noping like the usual CU templates, but it is later stricken when a different template is used. Try AIV, which basically uses the same noping mechanism. this is a blue userpage which isn't stricken. This is a non-existent user page which is blue and also not stricken. The striking does work for IPs at AIV (eg) which have red userpages, but not IP contributions listed at WP:OPD which are now not stricken. Previously, I think I'm right in saying, all these links were stricken. -- zzuuzz(talk) 21:31, 2 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Anachronist suggested me to try asking for this request here
The ip range 151.48.0.0/17 was globally blocked by a steward because a user from this ip range used it to create several fake accounts and spam messages accross wikipedia
Anachronist unblocked locally in en.wikipedia.org the possibility to create accounts from this ip range but there must be a glitch or a bug because if i try creating an account from the blocked ip range appears the same error message
'Editing from your IP address range (151.48.0.0/17) has been blocked (disabled) on all Wikimedia wikis until 19:38, 13 December 2019 by Masti (meta.wikimedia.org) for the following reason:
Cross-wiki spam: spambot
This block began on 19:38, 13 June 2019'
I would like a sysop or someone else to fix this error please
Anyway if the cause of the block was an abuser who created too many accounts to spam messages i wonder why it was not chosen to keep the creation of accounts blocked and let edits from normal ip addresses unblocked but exactly the opposite
This isn't a technical issue. The range was blocked here, then it was additionally blocked globally with a wider scope - everything is working properly. You can ask over at WP:AN if you think we should put in an override to the global block for some reason. — xaosfluxTalk 18:12, 26 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
But it is true that for some reason it was reblocked globally with the same settings by another steward after its local unblocking and perhaps this is the cause of the glitch
@Semplicemente Agghiacciante: Yes sorry, had my dates backwards! So basically the additional local block did nothing except for ensure that range is blocked here even if the global block were to be removed. The "local settings" were not changed, an overlapping additional block was added. You could ask Anachronist to override the global block if they want to. — xaosfluxTalk 15:03, 27 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
So i have to ask for a special treatment for this globl block locally
I thought that a sysop was normally able to override a global block to allow users to edit or creating accounts locally but i was wrong
It is strange though because there are global blocks for italian ip ranges which are normally overridden in it.wikipedia.org
I do not understand what difference there might be if i ask an english sysop to try overriding the block as i have already done and if i ask for the same thing in the noticeboard but i will do as you told me
This should be a technical issue not something about permissions or groups
Clicking on this link causes my processor to jump into overload and the page completely freezes. This happens in Linux Chrome 75 (not FF) private or standard mode. Is anyone else experiencing this issue? In IRC, User:AntiCompositeNumber mentioned it took longer than average but it did load for him. Magog the Ogre (t • c) 15:32, 28 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
The page loads normally for me in Google Chrome 75 on Linux until it gets to File:ImbaKernale1936.tiff, which is displayed as a png thumbnail in the page. The thumbnail takes approximately 30 seconds to load, during which time part of the page does not render, links do not work, and Chrome task manager show the tab as using ~100% CPU. Loading the thumbnail directly produces the same issue: 30s load time and 100% CPU. On Firefox, the thumbnail loads in 2000ms with maybe 10% cpu. --AntiCompositeNumber (talk) 16:02, 28 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
The file is a 21 MB tiff which is unnecessarily large IMO. Maybe a reduced sized JPG version could be created (as a new file on Commons) for use in Wiki pages. -- GreenC 16:34, 28 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
A conversion to JPG might also reveal any errors in the tiff that are causing rendering problems in browsers. When I try to view the tiff in Firefox and then "+" to expand to full size it doesn't work but prompts for file download. -- GreenC 16:40, 28 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
The TIFF seems to be a valid TIFF. But it contains a large block of data (about 20M of the 21M file) that's some sort of "Adobe Photoshop Document Data Block". That gets copied into the PNG thumbnail, and apparently the excessively large PNG chunk is making Chrome do a lot of work to process it. I have no idea whether the data in this huge block is legitimate Photoshop data or something else embedded. Anomie⚔ 23:33, 28 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
It was broken by this edit which added the identifiers here for the first time. NLP with 2K+ pages is broken too. For instance; its regex requires every id to be prefixed with 9810- but the 2500+ broken pages seem to be using IDs in the form of A12345678; i.e 'A' prefix followed by 8 numbers. If the regex by Tom.Reding is correct, then all those ids have to be corrected from Wikidata otherwise the regex needs to be corrected. – Ammarpad (talk) 09:20, 3 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
At template talk I investigated two of the errors and found that the template is correct, namely that the values in Wikidata are invalid. Can anyone find an id that causes an error to display yet which works when its link is clicked at the article's Wikidata item? Johnuniq (talk) 11:07, 3 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
If values of an identifier are incorrect on Wikidata, they should never have been added to Authority Control. Could someone please revert all of those non-working additions until such time as the information for them on Wikidata is correct? Softlavender (talk) 11:25, 3 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Hi Techy Wikipedians, I'd like to invite you to try out an open source tool we are actively developing: WikiLoop Battlefield. It's goal is to make monitoring Wikipedia incoming edits, in particular, potential vandalism, easier.
@Xinbenlv: For the "what links here" page to function, it's better to link to the page using wiki-markup: Wikipedia:WikiLoop Battlefield. I had an incredibly frustrating experience earlier this afternoon because a user made an incomplete revert with this tool, which shouldn't even be possible in the first place, at Federation of Australia, an article on my watchlist. It was difficult to figure out where to report the issue; I've added the GitHub link to the project page and reported it there. I also wrote a message on Meta; I don't feel like reporting the second issue there to GitHub because it's so minor, but it's about where the link in the edit summary should go. I consider the first issue so major that I don't think the program should make any more edits until it is fixed. Graham87 07:00, 4 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Hi, Yesterday night I'd reinstated my userpage however I've noticed a few barnstar pictures not showing on my userpage or at User:Davey2010/Barnstars,
I've tried CTRL & F5 as well as WP:PURGE but nothing's working?, The pictures show on other editors userpages so I would assume it's either related to my barnstars page or my laptop?,
Thanks, –Davey2010Talk 14:31, 4 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Ah okay, Tried Firefox and it does work there so reading your reply I would obviously say it's something wrong with Chrome,
Downloaded IE but it wants me to restart the laptop in order to install it ... something I can't be bothered to do given the length of time it takes for this machine to boot up ... so we'll assume it works on there too :),
Thank you Redrose64. I noticed that now I have the option to override individual settings now, and that the gadgets aren't available globally. It's still enough to make any efforts outside en-wp a bit more similar. Appreciate the help folks. — Ched : ? — 21:17, 4 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Greetings, While viewing article Blue, it has a template link for {{Shades of blue}}
which I noticed is overflowing outside the box on the right side. Next, I clicked on {{Shades of cyan}} with the same issue. So I successfully added <br> to keep the lines within the cyan template box.
The problem comes from the fact that {{navbox}} (in Module:Navbox) applies the class "nowraplinks" to the table, preventing all the links from wrapping. Rather than adding <br> all over the place, there should probably be a way for {{Shades of color}} to somehow avoid the use of that class in the first place. Anomie⚔ 19:11, 4 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
The snowman issue happened after I copied text from one section to the other, it didn't move and was instead replaced by snowmen. Before that, both the template and image adding functions hanged at least once, forcing me to close-and-reopen the browser tab to un-hang it. Jo-Jo Eumerus (talk, contributions) 21:43, 1 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
guess: this has nothing to do with VE specifically. it's Aug 1, and the code version was updated today (see Special:Version). during and shortly after update, strange non-reproducible bugs tend to pop up, usually as a result of browser running mix of sources from old and new versions. putting it a bit differently, the browser sometimes uses cached source file from yesterday's version in conjunction with other, fresh files from today's. complete refresh (usually Ctrl-refresh, but may depend on browser) will update all the sources to the new version and solve the issue. unfortunately, closing and opening the browser, or doing a simple refresh, isn't always enough. it used to be very common issue around the time of software update. i was under the impression that it was solved, but recently i saw several new cases of "Inexplicit bugs on the day of SW update". peace - קיפודנחש (aka kipod) (talk) 22:02, 1 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
For the past several days, I have been unable to convert bare url references using the Visual Editor. Normally, while in Visual Editor mode, I can click on a numbered bare url reference and a "convert box" appears on screen. Well, the "convert box" still pops up on screen, but there is no longer a "convert" button inside the box. Does not matter if I am using Google Chrome, Microsoft Edge, or Mozilla Firefox browsers; Visual Editor will no longer convert bare url's. Woodlot (talk) 17:22, 4 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 6 August. It will be on non-Wikipedia wikis and some Wikipedias from 7 August. It will be on all wikis from 8 August (calendar).
Problems
A change in RelatedArticles extension accidentally enabled it for everyone, not just for mobile users. This has been fixed. [35][36]
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 7 August at 15:00 (UTC). See how to join.
Future changes
Today everyone can see IP addresses if someone edits without an account. In the future this could be more hidden. This is to protect unregistered editors so fewer can see their IP address. This would only happen after we make sure the tools for vandal fighting can still be effective. You can read more and comment.
The operator, User:Slakr, hasn't edited since 22 July. Maybe something crashed with the bot and Slakr hasn't noticed the problem yet? Or maybe a MediaWiki software change affected something on which the bot depended, making it unable to function? I doubt there's any way to identify the precise problem until Slakr returns to activity — since the source code has not been published, only the operator knows how the bot works, and only the operator can figure out what critical processes may have been broken. And of course, only the operator can check to see if the operator's personal computer has stopped working properly at home. Nyttend (talk) 21:04, 4 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Can't find any sinebot stuff on Toolforge; I could be looking in the wrong place, of course, but that doesn't bode well for someone else being able to take over. While I was poking around, I found a project called mh-signbot, maintained by Zppix and a couple of other people, that seems to have some promising-looking Python code. I will read it more closely and look into running it (and someone else isn't already set up to run it, of course). Enterprisey (talk!) 09:28, 5 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
mh-signbot was a fork by them to operate on Miraheze, which didn't work out at the time due to them lacking eventstreams, no idea about its current state. There are also quite a few other forks, the one I know best is dewiki fork (de:Special:Contribs/CountCountBot), which I haven't had the time to look into closely and upstream any changes, and is worsened by the fact that I did a restructure of the code right after they forked it, but before I noticed the fork... Unfortunately, the code is doomed to deadlock at some point and needs manual restarting.
As for running it here, I would very much prefer a local bot op to operate it. There are a few site-local customizations that needs changing. The latest code of upstream Commons one is on gist. I'm happy to help if you run into technical issues. --Zhuyifei1999 (talk) 15:26, 5 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Nyttend and Eman235: yea - someone should open a phab ticket, it isn't the template per se, but if a span is used on a table headerer with wikitable sortable, the label is turned in to the control when it isn't expected to be... — xaosfluxTalk 22:14, 4 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
More specifically, the problem is that the JS tablesorter code tries to avoid triggering when a link is clicked, but it only special-cases clicks on the <a> element itself. With {{colored link}}, it sees the <span> used for applying the coloring as the thing clicked and doesn't bother to check whether that <span> is inside of an <a>. This would also happen with things like italic or bold markup inside a link in a table header, basically anything where there's a tag inside the <a>. Anomie⚔ 12:01, 5 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
┌─────────────────┘ For the list of minor planets: 541001–542000 and friends, the standard, light-grey color for wikitable headers is undesirable, because it is too similar to the existing color palette used for the table rows. Is there a WP:POLICY that forbids changing the table-header color despite good reasons? While the link and sort features are currently in conflict with each other, the middle mouse button still works. I'm currently testing a work-around for said conflict. If no simple solution can be found, the table's sortability feature will have to go. Rfassbind– talk 21:42, 4 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
The problem with using multiple colors for meaning is that it's sometimes not as accessible for colorblind people like me, and it's meaningless to the blind. But it sounds like you're doing this just for variation, in a situation where variation has a practical benefit. That should be fine as far as accessibility is concerned, but if you use multiple colors, users will expect meaning to be associated with the different colors, and "random" use of colors will be confusing. If your exclusive purpose is distinguishing the text from something else, why not just pick one color and use it consistently? Either users won't notice, or they'll notice and not be confused. Also, the middle mouse button doesn't always work: when I do a middle-click with my mouse, it brings up something that's intended to let me choose an open window to use (browser, calculator, Notepad, etc.) and doesn't open a new browser tab with the link target, as it did on my previous computers. I'm using Windows 10 with Internet Explorer; I don't know if other browsers or other operating systems will behave the same way. However, if I'm using the touchpad on the same computer, I don't have a middle mouse button, and I have no idea if there's an analogous feature for people who edit on smartphones. Nyttend (talk) 22:04, 4 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Graham87, could you check this table and tell us how your screen reader handles it? This table has six lines: "Designation and Discovery" appear on the first line (a header), "Permanent" and "Provisional" and "Citation" and "Date" and "Site" and "Discoverer(s)" and "Category" and "Diam." appear on the second (also a header), the third is spots where one can click to re-sort, and data appear on the fourth through the sixth. Also, there's a "Ref" header that appears in a merged first and second line. Nyttend backup (talk) 16:34, 5 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Hi everyone! Just wrote a new user script. I don't usually announce new ones here, but I think this one is pretty useful. With this script, you can add custom keyboard shortcuts that will take you to any page. You can also have sub-menus, which allow for key sequences. Documentation is at User:Enterprisey/superjump, code is at User:Enterprisey/superjump.js, and I wrote a config tool so you don't have to write JSON if you don't want to. Feedback is welcome! Enterprisey (talk!) 07:19, 28 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I can't get the xtools.wmflabs.org "Edit count" tool to work, either on overall edits by an editor or an editor's edits per page. It just keeps loading and then times out, with the message "Sorry, the requested information took too long to process (timeout 600 seconds). In order to save resources, the query was automatically killed." Help! Softlavender (talk) 02:31, 6 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Softlavender: Everything is in working order on my end. Could you give examples? I'm assuming you were looking up a user with a very high edit count, or a page with a very high revision count. In these cases it is expected to go slow and unfortunately sometimes timeout. That said, the database servers have been performing very well as of late, so you shouldn't see this error very often.
@Softlavender: Thanks. AN/I is one of those pages that is less likely to be successful :( There are over a million edits to scan. I can try to make it only search the past N revisions or something, so that you can at least get some data.
I have never had the Edit Counter to time out when searching prolific users' edits to ANI, and I have done that search often with many prolific ANI posters (i.e., posting many hundreds of times to ANI). Can someone please fix it? Thanks. Softlavender (talk) 03:27, 6 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
It took nearly 20 minutes, but I did get results using Sigma's tool, so feel free to use that as an alternative, since it doesn't seem to have a time limit. You have made a lot of edits to AN/I, so perhaps this combined with the long history of AN/I is what's making it so slow. There are many other factors; it's hard to say why your account times out and not others.
I'm guessing that this new format and version [38], which looks nothing like the old format and version, is the problem, but no one wants to admit it doesn't work. Could we therefore revert to the previous, working version? Softlavender (talk) 03:46, 6 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Hmm the last change to Top Edits was on May 29, and that was supposed to make it go faster, not slower. I just replied to you above; it seems there's something especially slow about your account + AN/I, and it's not unique to XTools. Use Sigma's tool for now since it doesn't have a time limit. I've changed MediaWiki:Histlegend to link to this tool, too (it was changed to XTools because at the time Sigma's tools were down). — MusikAnimaltalk 04:38, 6 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I don't think there were any code changes that caused this. Database queries can be very complex with many factors that could cause them to be slow. It may have been not-slow before, but AN/I has since grown, or perhaps the problem is that a lot of people are using the database servers right now. It's not easy to debug, but queries timing out for a pages like AN/I is really of no surprise. Sigma's tool is struggling too in this case, but as I stated above, MediaWiki:Histlegend has been updated to link to it. — MusikAnimaltalk 05:24, 6 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Here is the 7th issue of the Bots Newsletter, a lot happened since last year's newsletter! You can subscribe/unsubscribe from future newsletters by adding/removing your name from this list.
BAG members are expected to be active on Wikipedia to have their finger on the pulse of the community. After two years without any bot-related activity (such as posting on bot-related pages, posting on a bot's talk page, or operating a bot), BAG members will be retired from BAG following a one-week notice. Retired members can re-apply for BAG membership as normal if they wish to rejoin the BAG.
We thank former members for their service and wish Madman a happy retirement. We note that Madman and BU Rob13 were not inactive and could resume their BAG positions if they so wished, should their retirements happens to be temporary.
Activity requirements: BAG members now have an activity requirement. The requirements are very light, one only needs to be involved in a bot-related area at some point within the last two years. For purpose of meeting these requirements, discussing a bot-related matter anywhere on Wikipedia counts, as does operating a bot (RFC).
Copyvio flag: Bot accounts may be additionally marked by a bureaucrat upon BAG request as being in the "copyviobot" user group on Wikipedia. This flag allows using the API to add metadata to edits for use in the New pages feed (discussion). There is currently 1 bot using this functionality.
Mass creation: The restriction on mass-creation (semi-automated or automated) was extended from articles, to all content-pages. There are subtleties, but content here broadly means whatever a reader could land on when browsing the mainspace in normal circumstances (e.g. Mainspace, Books, most Categories, Portals, ...). There is also a warning that WP:MEATBOT still applies in other areas (e.g. Redirects, Wikipedia namespace, Help, maintenance categories, ...) not explicitely covered by WP:MASSCREATION.
I'm looking for the external tool which allows (even to non-admins) to display the list of a user's "deleted edits" (actually, I think it was the list of deleted pages they created or edited). IIRC it looked like [40] (which provides a "deleted edit" links that redirects to Special:DeletedContributions, which can be used only by admins).
Currently and since Wikipedia articles and Wikidata items have been connected, the link “Wikidata item” appears on the menu column, in the section “Tools”.
However, many editors from various projects told us that it would make more sense to have the link in the “In other projects” section, since Wikidata is one of the Wikimedia projects and the Wikidata item link doesn’t really belong to the list of special pages.
This is why we are going to change the position of the link, on August 22nd for all Wikipedias and August 21st for all the other projects. After this date, you will find the “Wikidata item” link in the “In other projects” section.
In some cases, for example on help and meta pages, the section may contain two links to Wikidata, for example on Help:Contents where there will be the “Wikidata” link (linking to d:Help:Contents) and the “Wikidata item” link (linking to d:Q914807).
If you want to know more about the previous discussions or mention a bug or an issue, please add a comment to the related Phabricator task. If you want to reply to me onwiki, please ping me so I don’t miss your message.
Hello everyone, I'm from ckbwiki. Why Wikipedia (the mostest vistors and editors site) hasn't Dark mode feature yet?! Please try to add that feature. Some of editors edit Wikipedia at night. Our eyes are tired from white screen at night and changed to red soon. Please try to add it! Thanks! ⇒ AramTalk 18:28, 8 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Basically the header. Very very often I revert vandalism or otherwise unconstructive edits to talk pages, but I can't use the rollback or undo buttons because sinebot already signed it, so now I have to revert two edits by two different users. Is there any tool or javascript or something that would let me revert such a pair of edits as easily as using rollback? Someguy1221 (talk) 07:48, 9 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Someone should fork that or convert it to a gadget, relying on other people's personal scripts leads to exactly this situation when they stop being maintained. That being said, if someone has a very minor fix to suggest, drop an edit request at User talk:GregU/dashes.js and an interface admin will consider it. — xaosfluxTalk 11:40, 9 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
That category doesn't exist. Nor does the name actually match the use you propose for it (not all redirects are "target different from correct name"). Also, what use would there be to a category containing every redirect? You could as well use Special:ListRedirects. Anomie⚔ 14:25, 9 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Oh, I see what happened. The refresh changes indicator got wrapped up into the Active Filters 'show/hide' box. I might have to request that one be reverted (did so--see phab:T230220)... So, it looks like I'm all good. --Izno (talk) 17:22, 9 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I was never asked before to update the NUMBEROF template in simple Wikipedia. Now I ran the bot once to update it, and can run it regularly, e.g. daily, in the future. Are there any objections? — Ace111 (talk) 17:02, 10 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Ace111: and others - FWIW - Thank you *very much* for your comments - and efforts/updates and all - they're all *greatly* appreciated - I have no objection whatsoever re regular daily updates of the Simple English Wikipedia (or related) in the future - Thanks again - and - Enjoy! :) Drbogdan (talk) 17:27, 10 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Daß Wölf: all ways of accessing the image show the ε correctly for me. The difference is likely to be caused by how the glyph is specified in the SVG; if it's by giving font details, you may not have the font on your system (I'm using MacOS). Depending on how the SVG file is created, there are different ways of specifying how characters should be saved. Peter coxhead (talk) 07:45, 10 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Yes, it seems so, but it was actually gone before that revision. I refreshed the page when I got Peter coxhead's ping at ~7:45 and it rendered correctly all on its own. DaßWölf 00:02, 11 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I used to be able to hide the active filters navigation since I have no need for it. The problem now is that it's also hiding the live updates button when I click "hide." Amaury • 14:25, 9 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I've been experiencing the same problem in my watchlist since roughly 8 August. I'm using the Vector skin in Firefox 68.0.1 on a Windows 10 (1903) desktop. I've tried running the watchlist in safemode, but it makes no difference. —Bruce1eetalk 15:10, 11 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
My userpage is currently linked to Wikipédia:Userbox/Reunificação da Irlandas on the Portuguese Wikipedia although that is not a userpage and I did not link it myself. I cannot find the link to edit interlanguage links on my userpage so I was wondering if anyone here knows how to remove the link or if they could direct me to the right process? I have not created a userpage in any other language as I do not have the expertise to do so without a professional translator. My only other userpages across Wikimedia are on Commons and Wiktionary and they are both in English. I have tried asking User:Cuchullain, who is an admin, but they cannot work it out and they advised me to try leaving a note here. Tk420 (talk) 19:25, 11 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
Editors using the mobile website on Wikipedia can opt-in to new advanced features via your settings page. This will give access to more interface links, special pages, and tools. Feedback on the discussion page is appreciated. [41]
Due to the absence of volunteer maintenance of Cologne Blue skin, the link to activate it will be hidden. The skin will still work, but editors using it are encouraged to switch to another skin. [42]
Changes later this week
Due to Wikimania, there is no deployment this week. [43]
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 13 August at 15:00 (UTC). See how to join.
Future changes
The "Wikidata item" link will be moved from "Tools" to "In other projects" section on all Wikimedia projects, starting on August 21. Full announcement, Phabricator task.
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. — JFGtalk 07:57, 12 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@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)(discussiontools-replybutton)[(discussiontools-replylink)]
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? — JFGtalk 21:30, 12 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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. --5.43.96.116 (talk) 05:40, 13 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
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.
I think the reason is that particular thumbnail returns the header says "content-type: application/x-www-form-urlencoded" instead of common "image/jpeg".
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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.jsNewsAndEventsGuy (talk) 18:59, 12 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@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)(discussiontools-replybutton)[(discussiontools-replylink)]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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)
Background
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.
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
@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)(discussiontools-replybutton)[(discussiontools-replylink)]
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:
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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)(discussiontools-replybutton)[(discussiontools-replylink)]
@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)(discussiontools-replybutton)[(discussiontools-replylink)]
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). --5.43.96.116 (talk) 05:44, 13 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
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. --5.43.96.116 (talk) 13:23, 13 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
┌──────────────────────┘@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). --5.43.96.116 (talk) 07:41, 17 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
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 sr.wiki 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. --5.43.96.116 (talk) 07:51, 17 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
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: [45]. 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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
Bot completion errors?
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)
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
{{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)(discussiontools-replybutton)[(discussiontools-replylink)]
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 huji—TALK 15:17, 18 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@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. huji—TALK 18:53, 18 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
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 ([46]). 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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Tech News
There will be no Tech News issue next week. The next issue of Tech News will be sent out on 2 September 2019.
Problems
Some abuse filters stopped working because of a code change. Only variables for the current action will work. Variables defined inside a branch may not work outside of that branch. You can read more to see how to fix the filters.
Only six accounts can be created from one IP address per day. Between 12 August and August 15 this was two accounts per day. This was because of a security issue. It is now six accounts per day again. [47]
Changes later this week
Only a limited number of accounts can be created from one IP address. An IP address can be whitelisted so that it can create as many accounts as needed. This is useful at events where many new persons learn to edit. IP addresses that are whitelisted for this reason will also not show CAPTCHAs when you create accounts. This will happen on Wednesday. [48]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 20 August. It will be on non-Wikipedia wikis and some Wikipedias from 21 August. It will be on all wikis from 22 August (calendar).
Meetings
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 21 August at 15:00 (UTC). See how to join.
Future changes
There is an RFC about creating a new global user group with the right to edit abuse filters. This will be used to fix broken filters and make sure all filters will still work when software changes happen. You can read more and comment.
Special:Contributions/newbies will no longer be working. This is because of performance reasons. It showed edits by new accounts. You can see this in the recent changes feed instead. [49]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
[A note for myself that the template help doc must be updated to match these changes, i.e. r/v recent additions]
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 (t 桜 c) 05:24, 12 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
:/* Automatically tick the "Move subpages" option when moving pages.*/:varmoveSubpagesBox=document.getElementsByName("wpMovesubpages")[0];:if(moveSubpagesBox!==undefined){:moveSubpagesBox.checked=true;:}:
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:
Draft:Declan Meagher
Draft:Gary Soulz
Draft:Ananth Narayanan
Draft:Frank Verboven
Draft:Maths Time Joy
Draft:Gary Soulz
Draft:Ananth Narayanan
Draft:Eni Vasili
Draft:Shorts México - Mexico International Short Film Festival
Category:Pending AfC submissions in userspace
Draft:John Haze
Draft:Alisha Rai (author)
Draft:Leonardo3 Museum
Draft:Wake. (2018 film)
Category:Pending AfC submissions in article space
Draft:Anastasiya Makarevich
Draft:Alisha Rai (author)
User:ItsYaBoiAustin/sandbox/Odyssey: Extraction
Draft:Scott Stambach
Draft:Christian Lillinger
Draft:Gudula Naiga Basaza
Draft:Scott Stambach
Draft:Katherine Boyer
Draft:Walter Ferguson
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.
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. huji—TALK 18:58, 18 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
(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 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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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 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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
@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? — xaosfluxTalk 13:02, 16 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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.
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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
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)(discussiontools-replybutton)[(discussiontools-replylink)]
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)(discussiontools-replybutton)[(discussiontools-replylink)]
Hello, I am one of the maintainers of User:WP 1.0 bot. We've recently changed the server architecture of the bot drastically. Instead of a single threaded cron job that runs once a day, we now have worker processes running as daemons that pick up any work that is added to the work queue. This is coupled with, of course, a cron job that runs once a day but simply adds work to the queue and exits.
I'm running into a problem with long running login sessions expiring (which is to be expected) and how to resolve the issue. The script is written in Python and uses mwclient to log in to English Wikipedia and perform edits as the bot. I've logged an issue on github about the problem.
Basically, I was wondering if anyone has encountered this before and knows how to resolve it. You can see my (convoluted) attempt in our source code. Note that site is a global variable so that login can be performed easily "pre-fork", by the worker startup script before the worker jobs themselves are forked.
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)(discussiontools-replybutton)[(discussiontools-replylink)]
Indirect, but probably one way of doing this would be to look at when sudden spurts of activity happen in logs of the #wikimedia-operations irc channel. Downtime usually corresponds with a lot of people asking what is going on, and a lot of spam from monitoring bots. You can also look at the pretty charts at grafana, like this one of edit rate [50] (As if the site is down, the editing stops). Bawolff (talk) 20:55, 21 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
So I've got this workflow problem where I'll click on the edit summary box, move the mouse cursor down to the "save" button, then type or paste an edit summary, and this annoying menu of unrelated edit summaries will pop up behind the mouse cursor. And because my mouse happens to be over this menu (even without clicking) (usually trying to move away from it and make it go away) whatever edit summarily I've entered will be replaced by whatever random thing is under the mouse cursor. Looks like this.
I had assumed this was some kind of browser feature for which I can't find the setting to turn it off, but then I considered that its degree of responsiveness is laggy to actually be a mediawiki javascript feature instead. Whatever it is, I just want to make it go away. I'm using Chromium "Version 76.0.3809.100 (Official Build) Built on Ubuntu, running on Ubuntu 18.04 (64-bit)" and the monobook skin, if any of that matters. ―cobaltcigs 00:05, 21 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
nice tip. i was not aware of this attribute. two minor comments:
according to [51], support for this attribute is relatively new on FF, and does not exist for IE browsers. if you use IE, too bad, and if you use FF, you need version 67 or higher (current is 68).
the snippet posted by SD0001 may not always work: if your common.js happen to finish loading before the page is fully formed, it can be a miss. you probably want something like
VPT is for technical issues. While the question is certainly valid, the instructions on the top of your .js page already state that you should trust the code you're putting into your script page, code which is accessible already, at the linkback link above and you can check it yourself before adding it to your script page. --qedk (t桜c) 17:09, 21 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Hey guys! Where can I see the rescue codes for my TFA? I lost access to the device that generated the codes for me, now I don’t know how to access it on my new device. •_•--▸ épinetalk♬ 13:44, 22 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Épine:Scratch Codes would be wherever you securely stored them. You only see these codes while setting up 2FA (and never again), so copy them from your browser and save them offline in a safe place (e.g. on a memory stick or paper printout). If you don't keep these codes and encounter a problem with your 2FA device, you will be locked out of your account. — xaosfluxTalk 13:47, 22 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Hello! I am writing here for the first time, so I apologize if I write in the wrong section.
I would like to draw the attention of Wikipedia administrators one inaccuracy in the template for Belarusian stadiums on the Wikimedia Commons. In the LOCATION field, instead of the current 2019 administrative-territorial structure of the country outdated information from the year of construction of the sports facility is indicated.
It turns out such nonsense: Dynama Stadium, Minsk built in 1934, but instead of a location in the country BELARUS, the card in the description indicates the states that existed in the 1930s on the territory of modern BELARUS — Lithuanian–Belorussian Soviet Socialist Republic, Byelorussian Soviet Socialist Republic.
Same thing with Central Stadium, Gomel. The stadium was built in the 1920s, but Gomel Povet and Mogilyov Viceroyalty no longer exists. By administrative-territorial structure of the Republic of BELARUS for 2019 all cities is part of the district, then the region, then the country. The capital city of Minsk is a separate administrative unit within BELARUS.
In this regard, I ask administrators to make the necessary changes to the card on the Wikimedia Commons for Belarusian stadiums so that outdated information does not mislead readers. If you want to make sure the veracity of my arguments, I can connect administrators from the Belarusian Wikipedia to the discussion. We will provide links to the official administrative-territorial structure of the Republic of BELARUS for the current time of 2019.
I still don't know what you refer to with "the card on the Wikimedia Commons for Belarusian stadiums". Please give precise steps to reproduce an example of the issue, e.g. "Click on Dinamo Stadium (Minsk), click on the coordinates in the infobox or do something else, click on X, now there is a map/box/whatever which says Y but should have said Z." PrimeHunter (talk) 18:17, 22 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
(edit conflict) @Football Beetle: OK, I think I've unraveled this. To summarize: You are not seeing a problem with the encyclopedia articles here on the English Wikipedia. You do think there is a problem with the data on certain pages at Wikimedia Commons, for example: commons:Category:Dynama Stadium, Minsk. For pages such as that on Wikimedia Commons, that data is usually generated via a template there, commons:Template:Wikidata Infobox, which in turn gets values from another project, WikiData. There should be a blue pencil icon at the bottom of those Infoboxes on commons that you can use to go to WikiData then make appropriate edits. For example, wikidata:Q4439085 has location properties (e.g. located in the administrative territorial entity) that you can update. Assuming this is correct, there is nothing that the English Wikipedia editors would directly do about this, but you can edit them directly. Does that help? — xaosfluxTalk 18:21, 22 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I will now explain in detail the essence of the problem. You correctly said that you first need to enter information about location of the stadium on WikiData. If the stadium was built in 2014, then on the Wikimedia Commons page of this stadium in the table in the upper right (Wikidata Infobox), the location is correct — Borisov, Borisov district, Minsk region, Belarus. And if the stadium was built in 1934, then information on the countries that existed on the territory of modern Belarus is indicated on the Wikimedia Commons. These countries and their parts were in the 1930s, but now they are no longer there. And on the page of the stadium on the Wikimedia Commons they are indicated, which misleads the reader. At the moment, all Belarusian stadiums are located on the territory of the Republic of Belarus and its administrative parts.
If this issue cannot be resolved with the administrators of the English Wikipedia, should I write the same thing to the administrators of the Wikimedia Commons? Just administrators from Belarus are not there, so I decided to write here first. --Football Beetle (talk) 18:52, 22 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
It doesn't look like you need an administrator at all, just go to the wikidata entry and make the improvement by editing it. Even if these were pages and values here on the English Wikipedia, "administrators" don't have any special authority over "content", anyone is welcome to make productive content updates at any time. — xaosfluxTalk 18:58, 22 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Now is the year 2019, not the 1950s. The indicated information is outdated and does not correspond to reality. This is the same if you write about the stadiums in Germany built in the 1930s on the Wikimedia Commons: LOCATION - BERLIN, THIRD REICH, instead of Berlin, Federal Republic of Germany. --Football Beetle (talk) 19:18, 22 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
Thanks for finding the right link commons:Category:Dynama Stadium, Minsk instead of the false links posted by the OP. It's not that easy to make the wanted change. Dinamo Stadium (Minsk) (Q1130487) says inception 1934 (when the stadium was built in Minsk). Minsk (Q2280) specifies "located in the administrative territorial entity" for Minsk at different times, e.g. "Byelorussian Soviet Socialist Republic" from 1930 to 1938. commons:Template:Wikidata Infobox apparently combines the construction year and correct location data for that year to say that the stadium is in the Byelorussian Soviet Socialist Republic. For a currently used facility like a stadium, it would be best to ignore the construction year and give the current location, but this choice may be hard to figure out for a template. I don't know how a user can fix it for this page without deleting the information in Minsk (Q2280) about where Minsk was located in the past. Don't do that. Such information has many other uses. This is really an issue for commons:Template talk:Wikidata Infobox and not the English Wikipedia. PrimeHunter (talk) 19:27, 22 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
@Headbomb: Searching rendered strings on the current page is logically impossible ({{#ifeq:{{string on page|{{PAGENAME}}|foo}}|0|foo}} would be a paradox). Searching non-transcluded parts of a rendered page might be possible but isn't easy to implement. Searching the source code of page already exists as Template:String count. * Pppery *it has begun... 21:43, 22 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
If the desire is to find or count strings on a rendered page, then the limitations make sense. If the desire is to find or count strings in the source, then I think that a module is required. Not tested but something like this:
local page_title_object;
if frame.args[2] then
page_title_object = mw.title.new(frame.args[2]); -- title object for the page specified in the template call
else
page_title_object = mw.title.getCurrentTitle(); -- title object for the current page
end
local text = page_title_object:getContent(); -- the unparsed content of the selected page
local _;
local count;
_, count = mw.ustring.gsub (text, frame.args[1], '%1'); -- count number of occurrences of frame.args[1] in frame.args[2]
return count;
not tested. Probably requires that Lua pattern sequences in frame.args[1] (the string to be found or counted) are escaped. Likely other stuff needs doing.
Before I go to Phabricator, may be someone experienced a similar problem or at least known on which side the problem is. I usually work on laptop, and there I am logged in all the time (I choose the option to log in for 180 days). On my Ipad, I used to be logged on all the time as well. Sometimes it behaved strangely: For example, a year ago I found myself in a situation when I was logged in the English Wikipedia but was not logged in for example on Commons; then I logged in to Commons as well and all was fine. A week ago, my Ipad installed an automatic update which presumably included a new version of Safari. I found myself logged out. I tried to log in and found that I can log in just into one project, but if I then open a new window with any Wikimedia project, I am not logged in. I can login there as well, but then the next window is not logged in and so on. Moreover, if I am logged in say to the English Wikipedia I can work all right (well, making sure I never backtrack to the login screen). However, after two days, I find myself not logged in. Every time I log in I tick the "180 days" option. I would appreciate any comments. Thanks.--Ymblanter (talk) 13:17, 22 August 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
--qedk (t 桜 c) 19:42, 21 June 2019 (UTC)
You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 3 July at 15:00 (UTC). See how to join.
Works for me - but the servers were just also having some hiccups, can you try again? — xaosflux Talk 20:59, 27 June 2019 (UTC)
Fixed The problem is that {{lang}} not only marks the text as non-English, it also adds 
You are invited to join the discussion at Wikipedia:Teahouse#Two questions about the WMF's Android app . Airbornemihir (talk) 04:32, 4 July 2019 (UTC)
Resolved 
Moved from Wikipedia:Village pump (miscellaneous)/Archive 62 § Has syntax highlighting CSS just changed?: ―Mandruss ☎ 21:58, 3 July 2019 (UTC)
to the left of "Advanced" in a toolbar then it doesn't change spacing for me in Google Chrome 75.0.3770.100. PrimeHunter (talk) 09:43, 4 July 2019 (UTC)
Glad to hear you resolved it. --qedk (t 桜 c) 07:05, 6 July 2019 (UTC)
Done @Timrollpickering: should be good now, is using the 'fake css' permission hack to make a protected user page. — xaosflux Talk 14:56, 9 July 2019 (UTC)
to start editing.
Estimated size of a printed version of Wikipedia (August 2010).
.svg)
FYI: Pointer to relevant discussion elsewhere. 
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)
Working - Update table? or Redirect page? .svg)
![[20]](https://en.wikipedia.org/w/index.php?title=Template:Largest_airline_alliances.svg&action=history){kind=link}
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)