<!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&oldid=25114640 -->
<!-- Message sent by User:Quiddity (WMF)@metawiki using the list at https://meta.wikimedia.org/w/index.php?title=Global_message_delivery/Targets/Tech_ambassadors&oldid=25114640 -->
== Planning for the last deployment of DiscussionTools ==
Please see [[Wikipedia talk:Talk pages project#Plan for the last deployment]]. I hear that the A/B test is in the data analysis phase, but I haven't heard what the results are. If the results turn out to be what they hoped for (see [[mw:Talk pages project/Usability/Analysis]]), the Editing team will be talking about deployments during the summer. They will be wrapping up the [[Wikipedia:Talk pages project]] and moving on to their new project, [[mw:Edit check]], whose first version will encourage editors to add inline citations. Please feel free to watch the new page and help them figure out how to make it hit the right balance between being useful and not getting in your way.
If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
All charts based on the graph extension have been disabled for over 40 days, impacting thousands of articles and millions of views. The latest official update on the situation was over a month ago. Can we have some news for people not directly involved in development work, but that invested a lot of work on writing and maintaining charts on Wikipedia? What is the current status? What is the timeline for re-enabling the extension? Thank you. Ita140188 (talk) 12:35, 30 May 2023 (UTC)[reply]
The status quo is that it is broken broken, and a direction for a fix (after the first attempt to fix it failed) is currently being sought but has not been chosen yet (and then a week of hackathon got in between). There is NO timeline. All of this is discussed in the tickets referenced. —TheDJ (talk • contribs) 19:28, 30 May 2023 (UTC)[reply]
@Ita140188 To clarify further. My estimation, is that after this first attempt to fix it failed, we are now looking at months and months of (unplanned) work before any sort of solution is created. As to the inevitable questions of "why do other website in the world not have this problem". Because they aren't being researched by security specialists in the same way as we get researched, nor do they generally allow untrusted users to modify the content of other users. —TheDJ (talk • contribs) 09:14, 31 May 2023 (UTC)[reply]
In any large wikipedia, the insertion of suspicious code into a graph would surely be detected by the local counter vandalism unit almost immediately? Looks like a risk worth taking for me. --45.156.242.189 (talk) 21:34, 31 May 2023 (UTC)[reply]
No it is not. That is like saying: surely because you can look at your bank account, there is no risk in someone else having your bank card and pincode. The problems we are talking about would basically give anyone full access to anyone else's user account. They are full and immediate compromises. —TheDJ (talk • contribs) 13:16, 1 June 2023 (UTC)[reply]
Regarding the lack of detail about what and where the holes are, I find that only to be expected. Here's the thing. If you've ever worked with IT security, you'll know that when a security issue occurs we reveal as little as possible about the problem. We need to somehow prevent people using the problem code, but we don't tell them any specifics. This is to try and prevent the security hole from being exploited until it's patched. So we say "there is a security issue with this facility, and until it is resolved the facility will not be available". Until a fix or replacement is available and is thoroughly tested, you need to live without it for a while longer. If you try and hurry us along, we may make mistakes, so we ignore the hurry-up calls and keep going at a pace that allows for all potential possibilities to be examined, leaving no stone unturned. Only when it's properly fixed up do we explain, and then only in the vaguest terms (just in case somebody is minded to try a similar exploit again) although we do record all the full details in a document hidden somewhere nobody would find it (in case it happens again and the previous fix needs to be examined thoroughly again).
Think of it like a building with a locked door, people with legitimate access are issued with a key to open the door. But somebody has found that they can open the door without the key using a bent paperclip and piece of chewing gum. So until a new and better lock is obtained and fitted, we block off the door entirely. What we do not do is say how the chewing gum was used.
So this is what it boils down to: the code that we were using has a hole and accordingly has been withdrawn from use, people are working on it, and until it's completely fixed to our satisfaction, that's all we're saying. --Redrose64 🌹 (talk) 14:33, 1 June 2023 (UTC)[reply]
The WMF actually deviates from that (otherwise excellent) analogy and often discloses the full details of security vulnerabilities once they are patched. And we do actually know the original security vulnerability that lead to Graph being disabled - it's disclosed at phab:T334895. That original vulnerability has been fixed, and some other (still undisclosed and unfixed) vulnerability in the same software is preventing the Graph extension from being redeployed now. * Pppery *it has begun...14:48, 1 June 2023 (UTC)[reply]
Well, there is always the option to move Vega graphs to EasyTimeline, sure, you would lose a lot of functionality, but at least it works. And no, I do not think that is a desperate move. Snævar (talk) 09:38, 4 June 2023 (UTC)[reply]
So, unofficial status: Originally Vega was disabled because of four known security vulnerabilities. Vega already had disclosed those at the time of the disabling, after all we where on Vega 2.5.2 and Vega has moved to Vega 5 at that point. Two of those vulnerabilities had proofs-of-concept and Vega is being run client-side, e.g. on your computer, so there was an active risk of hacking here. Then the Graph extension was updated to support Vega 5, solving the vulnerabilities in the process. It removed the protocols for getting data points externally, like from wikidata, the data namespace on commons, and so on. That is now done with calls to the API with user provided urls. That version did not support Wikidata, but most of the other external loading was there. They where planning a deployment of that, but decided to cancel it less than a week before the proposed date. This new version is active on beta english wikipedia.
Since then, a new vulnerability has popped up (we know, because there is an hidden bug) and Vega is not safe enough to be editable for every user on the wiki. We do know that editing Vega is going to be restricted (probably to admins) and that the code for Vega graphs on the wiki is going to shrink, whith the types of graphs being defined in one place, which Vega-Lite does do internally. The url external loading is planned to be removed and we will once again get an short field to fill for loading datapoints, this time in the graph tag. The belief from developers is that users are capable of identifying an vulnerability and not save it on the wiki, and that is the main mitigation moving forward.
So, some speculation. It has been confirmed that moving to Vega-Lite is not enough. Vega-Lite does have some interactivity and ability to change data points (in Vega's transform), but it has pre-defined types of graphs and how they are displayed. That is pretty much all there is to Vega-Lite. There is very little customizability compared to the full Vega. Even Vega 2.5.2 graphs, like we have on this wiki currently, are limited on Vega-Lite 5. If they limit Vega beyond Vega-Lite, considering Vega-Lite is not enough, then some of those features are going away. Snævar (talk) 09:12, 5 June 2023 (UTC)[reply]
Can I get a list of cite web templates that probably have excessive numbers of authors in the fields?
I keep coming across instances of {{cite web}} templates with multiple author names crammed into the "first=" or "first1=" parameter (for example, this template for which I have just fixed spacing). I believe this is caused by errant scraping by citation generators. Whatever the cause, I would like to fix these to the extent possible. The tell for them is usually a comma between names, so I would like a list of all pages that contain a {{cite web}} template with a "first=" or "first1=" parameter, where that parameter contains a comma. If someone can give me the list, I'll take it from there. Cheers! BD2412T23:23, 30 May 2023 (UTC)[reply]
Edited those two CNN sources as "cite news". For the longer author list, I edited the names in Vancouver format, and used "display-authors" to limit the display. Hope that is useful. Zefr (talk) 23:42, 30 May 2023 (UTC)[reply]
"200 pages in this category, out of approximately 37,116 total", sounds about right. I'll get on it. Cheers! BD2412T23:52, 30 May 2023 (UTC)[reply]
Do note that category is just this case with |last= and |author=, rather than |first= as you requested. But have fun! Izno (talk) 23:53, 30 May 2023 (UTC)[reply]
30k issues in the last name is an issue too. :) As I said, Help talk:CS1 if you think it would be beneficial to catch some of this in the first name field also. Izno (talk) 00:30, 31 May 2023 (UTC)[reply]
Also guaranteed to time out, got 2500+ hits for a single comma in |firstn=. Adding a maint cat for this might be a good idea. I'll do it tomorrow.
Excellent, thanks. I'll keep an eye out for it. I suspect that there may be some patterns with specific regularly cited journalist teams that can be addressed quickly. BD2412T00:43, 31 May 2023 (UTC)[reply]
A note: I poked through a few of the search results, and found a common pattern that is apparently caused by a bug in the beta Visual Editor's automatic citation template insertion tool. See this discussion for an initial report. – Jonesey95 (talk) 01:23, 31 May 2023 (UTC)[reply]
Probably not a bug directly in Citoid but a failure in the Zotero translator to deal with wherever the byline is that it's pulling. You can file a task in the Citoid project for each problematic domain. IznoPublic (talk) 02:25, 31 May 2023 (UTC)[reply]
Hey everyone. The A/B test I announced almost a month ago and then two weeks ago will finally be launched later today, Wednesday May 31. You may see it working on Hebrew Wikipedia if you're bucketed to the tested half of the logged-in users.
A brief reminder what this is about:
We're testing the new look (it's called Zebra) of the Vector 2022 skin in response to the volunteers' comments.
Compare the versions without the tested look and with the tested look. If you're not sure what's changing, pay attention to the background colors and borders around the content area and the side menus. Pin the left sidebar as a side menu.
More visual separation between regions of the interface may help draw more focus/attention to the content, make it easier to stay focused on the content while reading, and reduce screen glare and thus eye strain.
This is only a two-week test. After that, we'll roll back to the previous (all-white) look. Decision whether Zebra would stay will be made in July.
How to keep the new look? The URL parameter forcing it is ?VectorZebraDesign=1. While it's technically possible to use this to, say, create a browser plugin allowing us to only use Zebra or preventing us from seeing Zebra, we discourage from using it and getting used to it because this code will be temporary, just like the test itself.
I'll be immensely grateful for your collaboration, especially for explaining other Wikipedians why this change is happening and why there will be a change again in two weeks. I understand it may be confusing (like any change) and also worrying a bit (because lots of people may want to keep the change). Also, thanks for the feedback which led us to creating Zebra in the first place.
Similarly, the left-hand navbar has random blue text prefixed with "Toggle" appearing on the 'opened' sections when I click on it. Bit annoying. Can report this has happened on desktop view on Safari MacOS and also iPad OS. Hullian111 (talk) 06:19, 1 June 2023 (UTC)[reply]
If you look at that image above and right and do not see a general gray background against which the main "content" has a white background ("white panels"), then you need to calibrate your monitor's contrast. Izno (talk) 21:13, 31 May 2023 (UTC)[reply]
I can see it in the image provided, but I don't see it in the A/B example test pages given above when I try to look at them. —Tenryuu 🐲 ( 💬 • 📝 ) 21:18, 31 May 2023 (UTC)[reply]
You should also be able to see it in the with the tested look link. If you can see it in the image, that rules out hardware I think. How old is your browser? Izno (talk) 21:33, 31 May 2023 (UTC)[reply]
Most recently updated Chrome browser. Could be one of my Chrome extensions or a .css conflict, but I'm not particularly concerned about that if that's the case. —Tenryuu 🐲 ( 💬 • 📝 ) 22:26, 31 May 2023 (UTC)[reply]
Loved the new design. Is there any possibilities in the pipeline, regardless of A/B test result, for permanent opt in like through Preferences > Skin Preferences (like the existing "Enable responsive mode" and "Enable limited width mode" toggle) in which whoever interested can opt in? —Paper9oll(🔔 • 📝)13:14, 1 June 2023 (UTC)[reply]
Hello @Paper9oll and @QuickQuokka (answering the question asked below). Paper9oll, I'm very glad to learn that you like the new design. QuickQuokka, thank you, your kind words made me blush!
Currently, there's no way of opting out or "hard opting in". Zebra's code is written in a way assuming that it will either be dropped altogether or (more likely) become the default and only look. We don't have plans for making these versions (all-white and Zebra) parallel to choose between. Currently, the only way to see a more white look is to change the user CSS.
That said, I'd like to encourage everyone interested to subscribe to our newsletter which makes it easier to follow our updates. As I previously wrote, we most likely will be working on dark mode and other customizations like font size. Our plan isn't final yet, but among the options, besides dark mode, there might be sepia and/or an all-white version. This is not a promise, though!
The new design incorrect generates an underline on the main page (where the article title would be) despite there being no title. This line is correctly excluded in the previous version. Anarchyte (talk) 13:26, 1 June 2023 (UTC)[reply]
What puzzles me is this. If the changes were intended to improve visual separation of different blocks in the page by means of borders around certain blocks, and the darkening of backgrounds outside those blocks (both of which I am in favour of), how has it affected several other areas? --Redrose64 🌹 (talk) 16:03, 1 June 2023 (UTC)[reply]
It appears to be because Zebra uses selectors with higher specificity to override the default CSS, and some other CSS is also overridden by Zebra like collateral damage. Nardog (talk) 16:12, 1 June 2023 (UTC)[reply]
I saw that recently, there has been a new experiment to once again change up the skin from Vector 2022 to something new called Zebra. This kind of messes up dropdown menus among other things. I have two questions:
Where should I report this bug properly? I know phabricator exists, but I have never used it before and have no idea how it works at all. Already reported it on the village pump to the wonderful Mr. Szymon Grabarczuk of the Wikimedia Foundation.
How do I opt out of future A/B testing (if possible)?
The app you linked is not connected with Wikipedia. If that app does not work for you, please contact its supplier rather than us. If you are unable to use Wikipedia (for example, read or edit this page) on your mobile, please provide further details of how you tried to access it, what you expected to happen and what actually happened. Certes (talk) 11:20, 31 May 2023 (UTC)[reply]
I was bold and removed the link; the app it links to has nothing to do with Wikipedia and this being this user's first and only edit, makes me feel like this is some kind of SEO or spam situation. --Golbez (talk) 16:15, 1 June 2023 (UTC)[reply]
Has something changed in the last couple of days with the watchlists? In the past the list would tell me how many changes on a heavily edited page (AN & ANI are where i have noticed it) since i last visited it, if the last visit was the same day. At least twice in the past, perhaps, three days it is telling lies, in that i haven't visited a page but it shows a small number ~ lesser than the total changes in the day ~ since i last visited. It doesn't matter ~ i know where i've visited and the detail is just an added benefit, not an essential part of the watchlist ~ but i am curious about why the behaviour has changed. In case i'm not explaining clearly, i'm adding screenshot from a little while ago; i haven't visited either AN or ANI today, but both show a number of changes since i did? Happy days, ~ LindsayHello11:06, 1 June 2023 (UTC)[reply]
Addendum: I just revisted my watchlist and the numbers have changed, even though i've still not visited AN or ANI today. Strange. Happy days, ~ LindsayHello11:07, 1 June 2023 (UTC)[reply]
LindsayH is noting that the figures seem too high; if they had marked all pages visited, that would zero the figures, not increase them. --Redrose64 🌹 (talk) 11:54, 1 June 2023 (UTC)[reply]
It's a good idea, though i don't think i've ever actually clicked that button. I didn't, though; as the screenshot shows, not all pages have some changes since last visit, which they would if i had clicked it ~ Free grace theology, for example, shows 4 changes, but none since last visit. Happy days, ~ LindsayHello11:58, 1 June 2023 (UTC)[reply]
Here's an idea. Are the "changes since last visit" figures obtained directly from the live data tables, or from the Wiki Replicas? If the latter, we've had serious WP:REPLAG issues over the last week (see earlier in this page) and the Wiki Replicas may still be catching up, so data obtained from those can change without apparent explanation. --Redrose64 🌹 (talk) 12:01, 1 June 2023 (UTC)[reply]
MediaWiki features in production site don't use wiki replicas. They use the production replicas which don't lag by more than 5-10 seconds. If they do, mediawiki locks itself up in readonly mode and waits for the replicas to catch up. – SD0001 (talk) 07:28, 2 June 2023 (UTC)[reply]
Is it possible for MediaWiki to automatically create anchors to previous heading names?
Is this technically possible? Either in the header wikitext, or better yet, only at the page source level within the header tags.
Only for section names that change. This would make section linking permanent. It would greatly expand the utility of Wikipedia. For all sections in articles, talk pages, etc..
This would not produce duplicate IDs except in the rare case that a section name goes back to a previous section name. See example in User:Timeshifter/Sandbox197.
Maybe Mediawiki could automatically remove that duplicate ID: <span class="anchor" id="Current heading"></span> - in the wikitext. <span class="anchor" id="Current_heading"></span> - in the page source.
If it is automatic, then people would quickly notice span links in all section headings that change. The span links would be within the equal signs of the wikitext heading. But after the current heading, so that it is least interfering, and most intuitive. All changes in the heading would have anchors, so no links to sections would ever break.
It could be done only at a deeper level, at the page source level, so that editors never see anchor span tags in the header wikitext again.
Note: To be clear, I have given up on adding individual anchors manually to the current heading name. See #Template:Anchor discussion, and the discussion above it.
This is about an automatic process where editors wouldn't have to do anything. And in the best scenario they would see nothing added in the header wikitext. --Timeshifter (talk) 19:27, 1 June 2023 (UTC)[reply]
What defines a "previous" name ? There is no such thing in wikitext, it is just == something == surrounded by other random characters. Think of it this way. What if I take the entire text on this page, and then use it to replace whatever was your user talk page... Now what are the 'previous' anchors in this new revision. I honestly wouldn't know. And neither would a computer. —TheDJ (talk • contribs) 19:46, 1 June 2023 (UTC)[reply]
Mediawiki changes the heading in the page source when a heading is changed:
<span class="mw-headline" id="Current heading">
Could Mediawiki be made to notice that change in the current heading?
Also how does subscribing to individual sections of talk pages work? I looked in the page source of a talk page and could not find the word "subscribe" except when subscribing to the whole page.
Does subscribing to individual talk sections work after the section heading is changed?
If so, how is it done? Could that be used to add anchors to the previous heading?
Apparently, subscribing continues to work after a section name change:
Discussion notifications are implemented by the software storing subscriptions to the first comment, which has a unique ID assigned to it that includes the timestamp. This allows notifications to be performed even if the thread (including the first comment) is moved to another page. As I understand it, the headings are not used in the notification mechanism. isaacl (talk) 20:45, 1 June 2023 (UTC)[reply]
Thanks. I think this is the unique ID for this thread starting at "h"?:
commentname=h-Timeshifter-20230601192700
That is part of the unsubscribe link. The number is the date and UTC time of the first comment by me in this thread.
Maybe the unique ID could be used as the unique heading anchor for incoming links to this section:
A more elegant solution (without adding anything to the header wikitext) would be a "Copy link" button that produces this wikitext link:
[[Wikipedia:Village pump (technical)#h-Timeshifter-20230601192700|Wikipedia:Village pump (technical)#Is it possible for MediaWiki to automatically create anchors to previous heading names?]]
The anchor ID would be at the page source level, between the header tags.
I noticed that I am still subscribed to a VPT thread recently moved to the archives. So a unique anchor would work when sections are moved to archives.
I don't see any subscribe links on sections in articles. Only on talk pages.
Comments are identified by signatures. The notification mechanism does not operate on articles. The underlying challenge is if someone is restructuring an article, the section may no longer be an appropriate target for incoming links. If a new feature were to be introduced, personally I would prefer it to be a more general one of helping to find incoming links to a given URL fragment. This would allow editors to re-evaluate the links and determine the best target for them. isaacl (talk) 01:02, 2 June 2023 (UTC)[reply]
Personally, I would prefer a feature that makes it easier for me to find links pointing to a specific location on a page (that is, using the #fragment_identifier at the end of the URL). Thus if I wanted to restructure a page that affected any internal targets within it, I would be able to find any links pointing to those targets and evaluate what would be the best way to deal with them. (That being said, I'm not sure if the opportunity cost of implementing this feature is worthwhile.) isaacl (talk) 03:46, 2 June 2023 (UTC)[reply]
OK, I was not understanding "URL fragment" from your previous comment. #fragment_identifier is clear to me now. It encompasses old and new versions of a heading. It would be nice if there were a "WhatLinksHere" that worked for section headings. That showed where links to that heading were found. All versions of those links.
I am wanting a no-effort method based on Mediawiki automatically creating anchors anytime a section heading in an article is changed. It already automatically changes the span in the page source:
<span class="mw-headline" id="Current heading">
Maybe instead of deleting the old version it could convert it to
<span class="anchor" id="Old heading"></span>
That would mean from now on all links to article headings would be permanent. With no work required on the part of editors at all. --Timeshifter (talk) 04:34, 2 June 2023 (UTC)[reply]
XFDcloser removing RCAT templates when retargeting redirects
There is a bug with the XFDcloser gadget causing it to remove WP:RCAT templates and all other content in a redirect when closing an RfD discussion that results in a retarget. Here is a recent example. This creates problems for the few editors who watch redirects, as they must manually re-add the RCAT templates (and other content such as categories and hidden notes) if the closer neglects to do so, which is often the case. @Steel1943 and I have both raised this issue on the gadget's talk page, and I know others have noticed this bug as well, but it appears that the gadget's maintainer, Evad37, is no longer active on Wikipedia. I hope all is well with them, but I'm hoping someone else here will be able to address the bug and hopefully push out a fix. InfiniteNexus (talk) 22:20, 1 June 2023 (UTC)[reply]
It seems that people really like looking at page views of articles, etc. once they find a link or banner for it. Usually buried away on a few talk pages, revision history, or some gadget setting.
They especially like seeing page views over time via a bar graph or line graph. Which pageviews.wmcloud.org provides. Are there other places to link to? --Timeshifter (talk) 01:08, 3 June 2023 (UTC)[reply]
I imagine that it would not be difficult to make a user script that would place a link in an editor's Actions menu. Putting such a link as a permanent sidebar item for all pages for all users seems like a big step; I have edited here for over ten years and can't recall ever looking at or caring about pageview statistics. – Jonesey95 (talk) 01:35, 3 June 2023 (UTC)[reply]
I noticed you have created some articles. Aren't you curious? The page views timeline graph is available via a "pageviews" link found at the top of the revision history of an article. Many people never notice it since it is an obscure location. --Timeshifter (talk) 02:09, 3 June 2023 (UTC)[reply]
Not curious even an iota. Old person time: When I created my first web pages in 1994 and 1995, I was very curious about page views and saved all of the related stats in a spreadsheet that I probably still have around somewhere. The novelty wore off quickly. I would not change any of my behavior or beliefs in a positive way if I knew about the page stats; my editing is mostly intrinsically motivated. If you or anyone else feels or is motivated differently, that's wonderful, and someone probably has a script that will improve your life. – Jonesey95 (talk) 05:12, 3 June 2023 (UTC)[reply]
The English Wikipedia has added a pageviews link to the top of the page history and bottom of "Page information" for users witht the default interface language "en". User:PrimeHunter/Pageviews.js adds it to all pages. On disambiguation pages it also adds a link to show page views for all pages linked on the page. PrimeHunter (talk) 10:24, 3 June 2023 (UTC)[reply]
Thanks. I have had that installed for a bit. Sometimes it times out, even though it has already shown the bar chart. Then the chart goes blank. Has there been any discussion about adding the link to all articles, whether logged in or not? — Preceding unsigned comment added by Timeshifter (talk • contribs) 11:16, 3 June 2023 (UTC)[reply]
It should be fine. The worst that could happen is it will exceed its quota on connections to the wiki replicas, but that's only used to show the "edits"/"editors" stats which are not essential for this tool, and there are graceful fallbacks for when those queries fail.
German Wikipedia has a link to it on all pages, curiously at w:de:MediaWiki:Wikimedia-copyright which in my opinion is not the ideal location. I'm not sure if there's an interface page for the "Toolbox" (known as "Page tools" in Vector 2022), but that would be the best placement I think. We could use JavaScript as with the user script, but it feels wrong to do that just to add a link site-wide. — MusikAnimaltalk22:21, 5 June 2023 (UTC)[reply]
"Text is available under the Creative Commons Attribution-ShareAlike License 3.0; additional terms may apply. By using this site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization."
Graphs error message, an idea to make it more useful
Would it be possible to modify the error message displayed in place of graphs at this time to give a link to the page where the data is? I'm guessing that:
Graphs are temporarily unavailable due to technical issues. The data for this graph may be available here
probably wouldn't work, but I'm not sure how far from working it is. (Likely, "very")
But something similar (in output) would be good if it is workable. I didn't see anything in the original discussion about this, but since graphs may be down for a while (I can't see any time-til-fixed estimates on Phab, except from very early on), it might do to try to mitigate the effect somewhat. Mako001 (C) (T) 🇺🇦 12:09, 3 June 2023 (UTC)[reply]
The message is MediaWiki:Graph-disabled but the graph data is only in the generated wikitext for the page. There is currently nothing suitable we could link. Something very unsuitable to link for COVID-19 pandemic in India: Search for <graph> here. That's the entire template-expanded wikitext for the article. The two <graph> mark the start of the data for the two missing graphs. Good luck getting something useful out of that. PrimeHunter (talk) 20:09, 3 June 2023 (UTC)[reply]
Darn it. It seems my suggestion would only have a chance of working for a (very) limited number of graphs. It was based on graphs showing items in categories over time. I guess this can be closed now. Mako001 (C) (T) 🇺🇦 02:16, 4 June 2023 (UTC)[reply]
(edit conflict)@Bishonen: Ah, now I remember; the script I made does still work, it just doesn't do what I remembered. I've rewritten Þjarkur's script and blended it with mine at User:Writ_Keeper/Scripts/unmobilePlus.js. It should redirect you back to desktop whenever you get to a mobile link, but the mobile site will pop up for a second before it reloads to desktop, which I don't think is really avoidable. To minimize the impact of that, though, it will also do what my script originally did, which is go through and replace all links to mobile with direct links to desktop, so it should only be links you click on from outside Wikipedia that give you the mobile flash. That said, it does look like Þjarkur's original script still works for me (though it also gives the aforementioned mobile flash), and they work more or less the same way, so let me know if the new one works. Writ Keeper⚇♔16:14, 4 June 2023 (UTC)[reply]
On those links of yours, it's certainly working, and without the popping-up-for-a-second effect. I didn't understand the going-through-and-replacing-all-links thing, but then I probably don't need to. (Only links I click on from outside Wikipedia will give me the mobile flash? There is a world outside Wikipedia, with links in it? Mobile links?) Anyway, thank you very much. Bishonen | tålk16:32, 4 June 2023 (UTC).[reply]
I just came here to write about the same matter. reFill currently has two maintainers, one being me and the other is TheresNoTime. I think TNT is taking a break at the moment. I could do with a hand with someone well versed with Toolforge and Python to help with what looks like a virtualenv issue, probably quick and easy for someone with the right experience to solve. Ideally, it would be great to find someone willing to stick around beyond the current issue and become another maintainer.
The stack includes Vue.js, webpack, Celery, Redis, Python, Flask and of course Kubernetes.
I'd recommend hopping on #wikimedia-tech on IRC if you need help with the quick and easy question. There should be someone on there to help. Izno (talk) 17:01, 5 June 2023 (UTC)[reply]
Traceback (most recent call last): File "/data/project/afdstats/public_html/afdstats.py", line 90, in main db = MySQLdb.connect(db='enwiki_p', host="enwiki.labsdb", read_default_file=os.path.expanduser("~/replica.my.cnf")) File "/usr/lib/python2.7/dist-packages/MySQLdb/__init__.py", line 86, in Connect return Connection(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 204, in __init__ super(Connection, self).__init__(*args, **kwargs2) OperationalError: (2013, "Lost connection to MySQL server at 'handshake: reading initial communication packet', system error: 11") None
I'm afraid I won't be able to provide much insight. We at the Site Reliability Engineering team try to provide timely updates about issues regarding Wiki Websites stability (like on the locations you mention)- however, cloud services such as those are handled by separate teams (Wikimedia Cloud Services and Data Engineering) and while we'd love if all WMF teams shared our procedures, not all do at the time (and it makes sense not to update the general wiki status page for the general public for those more "internal" services- even if internal doesn't mean less important!).
I'm sorry I cannot provide further details as it is outside of my knowledge area and access rights (it seems to be a cloud networking issue), but I can see on the ticket someone from those teams is already working on it, so I would hope the issue gets fixed soon. Please be nice to them, as resources for maintaining those internal services are much more limited than for general Wiki maintenance and many are maintained only thanks to the help of volunteer administrators.-- JCrespo (WMF) (talk) 19:17, 5 June 2023 (UTC)[reply]
Tech News: 2023-23
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 RealMe extension allows you to mark URLs on your user page as verified for Mastodon and similar software.
Previously, clicking on someone else's link to Recent Changes with filters applied within the URL could unintentionally change your preference for "Group results by page". This has now been fixed. [3]
Problems
For a few days last week, some tools and bots returned outdated information due to database replication problems, and may have been down entirely while it was being fixed. These issues have now been fixed. [4]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 6 June. It will be on non-Wikipedia wikis and some Wikipedias from 7 June. It will be on all wikis from 8 June (calendar).
Bots will no longer be prevented from making edits because of URLs that match the spam blacklist. [5]
Planning for the last deployment of DiscussionTools
Please see Wikipedia talk:Talk pages project#Plan for the last deployment. I hear that the A/B test is in the data analysis phase, but I haven't heard what the results are. If the results turn out to be what they hoped for (see mw:Talk pages project/Usability/Analysis), the Editing team will be talking about deployments during the summer. They will be wrapping up the Wikipedia:Talk pages project and moving on to their new project, mw:Edit check, whose first version will encourage editors to add inline citations. Please feel free to watch the new page and help them figure out how to make it hit the right balance between being useful and not getting in your way.
--QuickQuokka [talk • contribs] 20:46, 31 May 2023 (UTC).
Citation and footnote editing can now be started from the reference list when using the visual editor. This feature request was voted #2 in the 2023 Community Wishlist Survey. [2]
The new version of MediaWiki will be on test wikis and MediaWiki.org from 6 June. It will be on non-Wikipedia wikis and some Wikipedias from 7 June. It will be on all wikis from 8 June (calendar).