Wikitech-l December 2024

wikitech-l@lists.wikimedia.org

27 participants
22 discussions

Announcing open beta of Catalyst (Kubernetes backend) on Patchdemo
by Stef Dunlap 14 Jan '25

14 Jan '25

Hi everyone, This is an information only message. There is no action required. We're excited to announce that Catalyst is now available in public beta on Patchdemo! Catalyst is an API that wraps a purpose-built CI Kubernetes cluster. Patchdemo uses Catalyst to deploy demos in their own pods, separated from other deployments. Catalyst adds isolation and an easier path forward to scale as more people use it. In the future, Catalyst will enable more complex testing topologies where, for instance, a service is needed alongside MediaWiki to test an extension that relies on that service. To kick the tires of the new Catalyst backend, you can visit https://patchdemo.wmcloud.org and check the "Use experimental Kubernetes backend" checkbox. The experience is mostly the same as the non-Catalyst use-case, except you'll see that logs are streamed from Kubernetes. During the public beta, this checkbox will default to being unchecked. We are eagerly accepting feedback on our Phabricator board: https://phabricator.wikimedia.org/tag/catalyst/ . You can also reach out on IRC to kindrobot or thcipriani on #wikimedia-cloud. You can read more about Catalyst at https://wikitech.wikimedia.org/wiki/Catalyst . Best, Stef Dunlap and the Catalyst team -- *Stef Dunlap* (they/she) Staff Software Engineer Wikimedia Foundation <https://wikimediafoundation.org/>

2 1

Proposal to improve cancellable promises in mw.Api [patch]
by Bartosz Dziewoński 13 Jan '25

13 Jan '25

Hi all, You're probably familiar with the mw.Api JavaScript class <https://doc.wikimedia.org/mediawiki-core/master/js/mw.Api.html> provided by MediaWiki, which can be used to make requests to our action API. promise = ( new mw.Api() ).get( /*...*/ ); You may also know that the promises it returns are enhanced with an .abort() method, which cancels the underlying HTTP request and rejects the promise. promise.abort(); The problem is that this method is only available on the original promise object. If you try to chain promises, it no longer works: promise.then( /*...*/ ).abort(); // Error: abort is not a function Copying this method to the chained promise is very cumbersome. I will spare you an example, but you can find it in the Phabricator task I filed for this problem: T346984 <https://phabricator.wikimedia.org/T346984>. It's also not possible to do if you use async/await, which we'll hopefully be able to use in MediaWiki code soon. The designers of the HTML5 Fetch API <https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API> came up with a different solution to the problem of cancelling HTTP requests: abort signals <https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#canc…>. The Fetch API is increasingly being used outside of the MediaWiki world, and so I would like to enhance our mw.Api to support the same approach. *Here's my proposal: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/959350* As you can tell by the six-digit patch number, I've had a hard time finding anyone else interested in this, so I'm sending out this call for reviewers. I hope there's someone out there with review rights who likes the idea as well :) You can read the documentation with examples of the new style here: https://patchdemo.wmcloud.org/wikis/ee373520a4/w/docs/js/mw.Api-AbortContro… The.abort() method is not being removed, and as a bonus, the patch includes improved documentation for that style of cancellable promises: https://patchdemo.wmcloud.org/wikis/ee373520a4/w/docs/js/mw.Api-AbortablePr… -- Bartosz Dziewoński

1 1

Announcing MediaWiki 1.43.0
by Mateus Santos 08 Jan '25

08 Jan '25

I am happy to announce the availability of the general release of MediaWiki 1.43! Tarballs have already been uploaded, and the git tag has been pushed. Thanks to everyone who helped out with this release, especially thanks to those who tested out the release candidate and provided feedback, as well as the developers who worked on fixes for the 1.43 final release. To see what's changed in 1.43, see the release notes file.[0] If you encounter any issues, please file a task.[1] You can see open tasks for the branch on Phabricator.[2] It’s important to highlight that this release marks the first led by the MediaWiki Engineering Group. We sincerely thank everyone who supported us as we continue to learn and enhance our processes to uphold our commitment to releasing MediaWiki as Open Source. MediaWiki 1.43 is due to be supported until the end of December 2027. === Changes since MediaWiki 1.43.0-rc.0 === * (T381728) Use PHP 8.3 in MediaWiki-Docker * (T382375) Misaligned label margins on Special:MathStatus * (T382196) \overbrace rendered below (not above) in MathML and client-side Mathjax * (T381310) Math Popup not working in newer version of Popup-Extension * (T380079) This page is using the deprecated ResourceLoader module "mediawiki.Uri" on page load * (T381311) Preview has wrong location in MathML mode * (T381046) Preview not working with MathML rendering * (T381102) <math>\left(a\right)'</math> in MathML and MathJax renders with one prime symbol too much * (T380184) <math>\operatorname{vec}</math> crashes with native MathML * (T380654) vertical space between multline equations is ignored * (T375274) mediawiki_function_names math functions eat the following paren in native MML mode * (T373732) Audit SUL3 shared-domain i18n messages for XSS * (T381068) PHP Deprecated: Creation of dynamic property MediaWiki\\Auth\\ButtonAuthenticationRequest::$skipReset is deprecated at AuthenticationRequest.php:182 * (T20110) Define AbuseFilter consequence to display a CAPTCHA * (T332743) On private wikis the ellipsis should not appear above 720px (wikitech, office, translate wiki) Release notes: [0] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/… Bug report form: [1] https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tags=MW-1.43-… Open Bugs: [2] https://phabricator.wikimedia.org/tag/mw-1.43-release/ ********************************************************************** Download: https://releases.wikimedia.org/mediawiki/1.43/mediawiki-1.43.0.tar.gz https://releases.wikimedia.org/mediawiki/1.43/mediawiki-1.43.0.zip Download without bundled extensions: https://releases.wikimedia.org/mediawiki/1.43/mediawiki-core-1.43.0.tar.gz https://releases.wikimedia.org/mediawiki/1.43/mediawiki-core-1.43.0.zip Patch to previous version (1.43.0-rc.0): https://releases.wikimedia.org/mediawiki/1.43/mediawiki-1.43.0.patch.gz https://releases.wikimedia.org/mediawiki/1.43/mediawiki-1.43.0.patch.zip GPG signatures for the above: https://releases.wikimedia.org/mediawiki/1.43/mediawiki-core-1.43.0.tar.gz.… https://releases.wikimedia.org/mediawiki/1.43/mediawiki-core-1.43.0.zip.sig https://releases.wikimedia.org/mediawiki/1.43/mediawiki-1.43.0.tar.gz.sig https://releases.wikimedia.org/mediawiki/1.43/mediawiki-1.43.0.zip.sig https://releases.wikimedia.org/mediawiki/1.43/mediawiki-1.43.0.patch.gz.sig https://releases.wikimedia.org/mediawiki/1.43/mediawiki-1.43.0.patch.zip.sig Public keys: https://www.mediawiki.org/keys/keys.html

5 5

Codex licensing issue
by diskdance 07 Jan '25

07 Jan '25

Dear all, I'm surprised to figure out that, Codex, the new design system and Vue component library of Wikimedia, is licensed under GPL, not LGPL or a permissive license. To me, this raises several problems: - The current license indicates that, code that uses the Vue components or design tokens from Codex has to be licensed under GPL as well. This can be problematic at times and is what LGPL is designed to solve. - I'm the maintainer of some on-wiki gadgets. Many of them are very tiny so licensing them under GPL doesn't make much sense -- in my humble opinion, GPL is designed for large projects so I usually choose a permissive license for them. If I use Codex in these projects, they can no longer be licensed under such licenses. I sincerely hope the maintainer of Codex can clarify this issue and provide solutions, if possible. Best regards, diskdance

6 9

Wikimedia developer satisfaction survey, December 2024
by Tyler Cipriani 02 Jan '25

02 Jan '25

Hello! Please take the December 2024 Developer Satisfaction Survey! Link: <https://wikimediafoundation.limesurvey.net/986172> The survey is open until **Fri, 3 January 2025**—four weeks from today. ____ This survey is for members of the Wikimedia developer community and covers the following topics: - Wikimedia Cloud Services - Development and shared test environments - Phabricator - Code review - Continuous integration - Deployment - MediaWiki Core backend components - APIs - Technical documentation - Research needs Please take the survey if you play a role in developing software for the Wikimedia ecosystem and would like to share your opinions on any of the topics listed above. We’re soliciting your feedback to: - Measure developer satisfaction, and - Determine where to invest resources in the future We will anonymize, explore, and report the data we gather on mediawiki.org. View previous years' survey results: <https://www.mediawiki.org/wiki/Developer_Satisfaction_Survey> Privacy statement: This survey will be conducted via a third-party service, which may subject it to additional terms. For more information on privacy and data-handling, see the privacy statement: <https://foundation.wikimedia.org/wiki/Legal:Developer_Satisfaction_Survey_2…> Thank you! Tyler Cipriani (he/him) Engineering Manager, Release Engineering Wikimedia Foundation

1 1

MediaWiki 1.41 is End of Life
by Sam Reed 21 Dec '24

21 Dec '24

As per the MediaWiki version lifecycle[1], I would like to announce the formal end of life (EOL) of MediaWiki 1.41 as of Tuesday December 31, 2024. 1.41.5 is expected to be the last release for this branch. This means that MediaWiki 1.41 will no longer receive maintenance or security backports. It is therefore strongly discouraged that you continue to use it. It is recommended to upgrade either to MediaWiki 1.42, which will be supported until June 2025 or to the next LTS, 1.43 (due to be released soon), which will be supported until at least December 2027. Thanks! [1] https://www.mediawiki.org/wiki/Version_lifecycle

1 0

Maintenance release: MediaWiki 1.39.11, 1.41.5 and 1.42.4
by Sam Reed 21 Dec '24

21 Dec '24

1 0

Excited to Contribute to Wikimedia Foundation
by nidha ahmed 20 Dec '24

20 Dec '24

Hi Sir/Madam, I hope you’re doing well. I am Nidha Ahmed, and a junior undergraduate student studying Artificial Intelligence and Data Science. I’m also going to join Google as an SWE Intern next summer. I’ve always been a huge admirer of the Wikimedia Foundation and its mission to make free educational content accessible to everyone. It’s incredible how your work empowers millions of learners around the globe, and I’m very eager to be part of this impact. I have experience with JavaScript, HTML, CSS, jQuery, ReactJS, and Python, and I’ve dabbled a bit in Android development as well. While I’m new to PHP and Ruby on Rails, I’m super excited to learn them! If you could share some resources or tips to get started with these technologies, it would be a huge help. A little about me: I’ve worked on projects like a movie recommendation system, a text summarization web app, and a geospatial analysis tool for public health. I’ve also contributed to open-source initiatives like designing real-time heatmaps for SoundScape. I’m looking to grow my skill set, hence I’m so drawn to Wikimedia. It would be helpful for me to get guidance on how to start contributing. I’m genuinely excited about the chance to learn from your community and support your amazing mission. I'm attaching my resume below for reference and proofs. Looking forward to hearing from you! Best regards, Nidha Ahmed Mohammad.

2 1

[Wikitech-l][Reminder] Join Let’s Connect and Share Your Wikitech Journey!
by Bukola James 20 Dec '24

20 Dec '24

Hi Wikimedians, I hope you’re doing well! My name is Bukola James <https://meta.wikimedia.org/wiki/User:Bukky658>, and I’m part of the Let’s Connect Working Group <https://meta.wikimedia.org/wiki/Grants:Knowledge_Sharing/Connect/Team>. This is a friendly reminder to join the Let’s Connect initiative, where Wikimedians like you can share, learn, and collaborate through monthly Connectathon, learning clinics, and newsletters. Interested? Sign up using this registration form <https://docs.google.com/forms/d/e/1FAIpQLSdiea87tSYmB2-1XHn_u8RLe7efMJifJBz…>. You’ll gain access to clinic resources, connect with others, and even host your own clinic <https://meta.wikimedia.org/wiki/Grants:Knowledge_Sharing/Connect/Calendar>s ! 📌 Note: The registration form is hosted on a third-party platform. Please review the Privacy Statement <https://foundation.wikimedia.org/wiki/Legal:Registration_for_Let%27s_Connec…> to learn how your data is handled. Got questions? Reach us anytime at letsconnectteam(a)wikimedia.org . Looking forward to connecting with you! Best regards, Bukola James Let’s Connect Working Group

1 0

Checking if template is rendered outside page content
by Marcin Szwarc 20 Dec '24

20 Dec '24

Hi! We at plwiki are in progress of refactoring the inplementation of standard {{mbox}} template family and unifying them into a single template. One of the tasks is to port these to TemplateStyles, instead of relying on global styles defined in MediaWiki: namespace. While it's quite easy for majority of the templates, an issue is {{fmbox}}, which is commonly used on special pages, edit intros, and edit notices. In these places, TemplateStyles don't work out of the box. An approach that I've thought of is to automatically wrap the actual message box with div of mw-parser-output class if the template is transcluded in these places, so as to enable TemplateStyles. (And do it conditionally, to have a common mbox for in-content and in-interface messages). Detecting whether we're at a special page should be pretty easy – checking the {{NAMESPACE}} should suffice. However, I don't think this will work for e.g. edit notice (I'd get the namespace of the edited page). So here comes the question: is there a reliable way to check when a template is transcluded outside of the standard page content (i.e. outside of .mw-parser-output)? Or, alternatively, to safely enable TemplateStyles in all places a template can be transcluded in, without breaking anything related to actual wiki content? Regards and thanks in advance, Marcin User:Msz2001

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l December 2024

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.