Wikitech-l January 2025

wikitech-l@lists.wikimedia.org

33 participants
45 discussions

January 2025: Technical Community Newsletter
by Deb Tankersley 13 Jan '25

13 Jan '25

Hello and Happy New Year! The quarterly Technical Community Newsletter for January 2025 is now available: https://www.mediawiki.org/wiki/Technical_Community_Newsletter/2025/January. This quarterly newsletter contains highlights, news, blog posts, and interesting information from and about the Wikimedia Technical Community. The Wikimedia Technical Community is large and diverse, and we know we can't capture everything. Got something you would like to see or something you want to highlight in the next quarterly newsletter? Add your suggestion to the talk page: https://www.mediawiki.org/wiki/Talk:Technical_Community_Newsletter. We would love to hear your ideas for future newsletters! To help your email inbox keep up with the latest updates and information, please subscribe to the Technical Community Newsletter: https://www.mediawiki.org/wiki/Newsletter:Technical_Community_Newsletter. Cheers, Deb -- deb tankersley (she/her) developer outreach program management Wikimedia Foundation

1 0

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

Breaking change: servicelib-golang logger
by Eric Evans 10 Jan '25

10 Jan '25

Hi, This is a heads up about a breaking change to mediawiki/services/servicelib-golang <https://gerrit.wikimedia.org/r/admin/repos/mediawiki/services/servicelib-go…>. If you don't maintain a service written in Go that uses this library, you can safely ignore this message. The logger that ships in mediawiki/services/servicelib-golang <https://gerrit.wikimedia.org/r/admin/repos/mediawiki/services/servicelib-go…> is meant to utilize Elastic Common Schema (ECS) <https://doc.wikimedia.org/ecs/>, but is missing a required attribute, ecs.version. Without that version string, log messages aren't handled as ECS events, they are processed and stored in the legacy manner. Any existing projects that upgrade to the latest version of the logger ( v1.0.0) will need to update any dashboards or saved searches to use the ecs-* index pattern (instead of logstash-*). https://phabricator.wikimedia.org/T383371 https://gerrit.wikimedia.org/r/c/mediawiki/services/servicelib-golang/+/110… Please reach out if you have any questions, or need any help with this. Thanks, -- Eric Evans <eevans(a)wikimedia.org> Staff SRE, Data Persistence Wikimedia Foundation

1 0

Invitation to the upcoming Commons Community Calls -- January 15, 2025
by Luca Martinelli [Sannita＠WMF] 09 Jan '25

09 Jan '25

Hello there! I am writing to let you know that the third round of community calls about Wikimedia Commons,[1] to help prioritize support efforts from Wikimedia Foundation for the 2025-2026 Fiscal Year, will take place next week. Our next call will focus on tool investment priority. There are constant calls from the community for the Foundation to adopt community-made tools in order to maintain workflows for the contributors that depend on them. The range of these tools varies widely, and includes media upload (e.g. Video2Commons), editing (e.g. CropTool), curation (e.g. Cat-a-lot) and metrics (e.g. BaGLAMa) tools. Batch upload and metrics tools are said to be critical for the affiliates and Wikimedians in Residence who partner with libraries and other cultural institutions to illustrate Wikipedia. They need to be able to contribute files efficiently at scale, and report on the impact of these contributions. However, community surveys have identified more than 30 different tools that are used for content partnerships. More specifically the questions will be: 1) Does it make sense for the Foundation to invest in supporting the wide range of community-developed tools that don’t have active maintainers, or should a smaller set of critical workflows be enabled through new or improved features in core products? 2) Which tool would you recommend to prioritise? Something community-facing or GLAM-facing or video-related or something else? The call will take place at two different time slots: * The first one will be on January 15, at 08:00 UTC,[2] and it will be hosted on Zoom by Senior Director of Product Management Runa Bhattacharjee; you can subscribe to it on Meta;[3] * The second one will be on January 15, at 16:00 UTC,[4] and it will be hosted on Zoom by Chief Product & Technology Officer Selena Deckelmann; you can subscribe to it on Meta.[5] If you cannot attend the meeting, you are invited to express your point of view at any time you want on the Commons community calls talk page.[6] We will also post the notes of the meeting on the project page, to give the possibility to read what was discussed also to those who couldn’t attend it. If you want, you are invited to share this invitation with all the people you think might be interested in this call. We hope to see you and/or read you very soon! Luca/Sannita [1] https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Commons_… [2] https://zonestamp.toolforge.org/1736928000 [3] https://meta.wikimedia.org/wiki/Event:Commons_community_discussion_-_15_Jan… [4] https://zonestamp.toolforge.org/1736956800 [5] https://meta.wikimedia.org/wiki/Event:Commons_community_discussion_-_15_Jan… [6] https://commons.wikimedia.org/wiki/Commons_talk:WMF_support_for_Commons/Com…

1 0

Final Reminder: Page content REST API rerouting
by Halley Coplin 09 Jan '25

09 Jan '25

Hi there, This is a final reminder for bot-operators and tool-maintainers that starting the week of January 13, we will begin rerouting some page content endpoints from RESTbase to the newer MediaWiki REST API endpoints. The impacted endpoints include getting page/revision metadata and rendered HTML content. Updated rerouting behavior is also available on the test wiki for any final testing that you would like to perform prior to the rollout. Although we intend for this change to be backwards compatible, non-breaking and therefore non-impacting, we encourage you to test and raise any final compatibility issues directly on the outstanding ticket in phabricator <https://phabricator.wikimedia.org/T374683>, or to me (hcoplin(a)wikimedia.org) directly. The specific endpoints that will be rerouted are listed below. More information about this change <https://phabricator.wikimedia.org/T374683> and the RESTbase Sunsetting project <https://phabricator.wikimedia.org/tag/restbase_sunsetting/> can also be found in phabricator. *Page & revision metadata endpoints: * - *GET* <domain>/api/rest_v1/page/title/{title} - Example: https://test.wikipedia.org/api/rest_v1/page/title/Earth - *GET* <domain>/api/rest_v1/page/title/{title}/{revision} - Example: https://test.wikipedia.org/api/rest_v1/page/title/Earth/604704 *Rendered HTML endpoints: * - *GET* <domain>/api/rest_v1/page/html/{title} - Example: https://test.wikipedia.org/api/rest_v1/page/html/Earth - *GET* <domain>/api/rest_v1/page/html/{title}/{revision} - Example: https://test.wikipedia.org/api/rest_v1/page/html/Earth/604704 If you have any questions, comments, or concerns, please don't hesitate to reach out via email or through phabricator. Thanks, Halley *Halley Coplin* (she/her) Sr. Product Manager, MediaWiki Interfaces Wikimedia Foundation <https://wikimediafoundation.org/>

3 2

Talk to the Search Platform / Query Service Team—January 8, 2025
by Guillaume Lederrey 08 Jan '25

08 Jan '25

Hello all! The Search Platform Team usually holds an open meeting on the first Wednesday of each month. Since this month would have been January 1st, we're moving to January 8 instead. Come talk to us about anything related to Wikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons Query Service (WCQS), etc.! Feel free to add your items to the Etherpad Agenda for the next meeting. Details for our next meeting: Date: Wednesday, January 8, 2025 Time: 16:00-17:00 UTC / 08:00 PDT / 11:00 EDT / 17:00 CET Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours Google Meet link: https://meet.google.com/vgj-bbeb-uyi Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927 Have fun and see you soon! Guillaume -- *Guillaume Lederrey* (he/him) Engineering Manager Wikimedia Foundation <https://wikimediafoundation.org/>

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

Subject: Aspiring Contributor for GSoC – Request for Guidance
by Prashi Jain 06 Jan '25

06 Jan '25

Dear Wikimedia, As my previous request has been blocked due to not being a member of list, i fulfilled the requirement now. My name is Prashi Jain, and I am currently pursuing a bachelor's degree in Data Science from IIT Madras. I am keenly interested in contributing to your organization through Google Summer of Code 2025 and wanted to reach out for guidance on how I can best prepare. While the projects for GSoC are yet to be announced, I would like to start building the skills and knowledge necessary to contribute effectively to your work. Could you please suggest any resources, repositories, or technologies that I should focus on to align with your organization's requirements? Additionally, I’d be grateful for any beginner-friendly tasks or areas where I can start contributing. Thank you for your time and support. I look forward to learning from your expertise and contributing meaningfully to your open-source initiatives. Best regards, Prashi Jain

2 1

Codex licensing issue
by diskdance 06 Jan '25

06 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

Breaking change: ZipDirectoryReader moved to Wikimedia\Mime
by Daniel Kinzler 06 Jan '25

06 Jan '25

This is a notification about a breaking change to the /ZipDirectoryReader /class in MediaWiki 1.44, as required by the Stable Interface Policy <https://www.mediawiki.org/wiki/Stable_interface_policy#Hard_deprecation>. If you do not maintain an extension that uses /ZipDirectoryReader/, you can ignore this message. *Summary*: The /ZipDirectoryReader /and /ZipDirectoryReaderError /classes have been moved <https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1107973> to the /mime analyzer/ library in the /Wikimedia\Mime /namespace. Furthermore, the return type of the /readHandle /method was widened from /Status /to /StatusValue/. Since this change to the return type is not backwards compatible, no class alias is provided. *Remedy*: If you need to use /ZipDirectoryReader /or /ZipDirectoryReaderError/, import them from the /Wikimedia\Mime/ namespace. If you are making use of the object returned by the /readHandle/ method, make sure you are not using any methods not present in /StatusValue/. *Rationale*: /ZipDirectoryReader/ is used by the /MimeAnalyzer /class, which is located in the /mime analyzer/ library in the /Wikimedia\Mime /namespace. However, /ZipDirectoryReader/ was part of MediaWiki code, so it's illegal for library code to access it <https://phabricator.wikimedia.org/T382910>. Since /MimeAnalyzer/ appears to be the only user of /ZipDirectoryReader/, the simplest solution was to move into the library as well. However, /ZipDirectoryReader/ was making use of the /Status /class, which again is part of MediaWiki core and this cannot be accessed from libraries. Only its more general base class, /StatusValue/, can. This made it necessary to change the return type of the /readHandle/ method. Since there are no users of /ZipDirectoryReader/ in any extension <https://codesearch.wmcloud.org/things/?q=ZipDirectoryReader> known to Code Search, the Stable Interface Policy allows the breaking change without a deprecation period. *Context*: This change is part of a long-term effort to extract generic code from MediaWiki core into libraries <https://www.mediawiki.org/wiki/Library_infrastructure_for_MediaWiki>, to reduce code complexity and improve code re-use. -- Daniel Kinzler Principal Software Engineer MediaWiki Engineering Group Wikimedia Foundation

1 0

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 January 2025