Wikitech-l April 2025

wikitech-l@lists.wikimedia.org

44 participants
35 discussions

Upcoming Language Community Meeting (May 30th, 15:00 UTC), Newsletter, and Namespaces
by Oscar Costero 25 Apr '25

25 Apr '25

*My apologies for writing in English. Please help translate to your language.* Hello everyone! We're excited to announce that the next *Language Community Meeting* is happening soon, *May 30th at 15:00 UTC*! If you’d like to join, simply *sign up on the wiki page* <https://www.mediawiki.org/wiki/Wikimedia_Language_and_Product_Localization/…> . This is a participant-driven meeting where we share updates on language-related projects, discuss technical challenges in language wikis, and collaborate on solutions. In our upcoming meeting, we plan to cover results from a recent language onboarding experiment and hear experiences from a Nigerian contributor who contributes to the Obolo wiki, which was part of this experiment. *Got a topic to share?* Whether it’s a technical update from your project, a challenge you need help with, or a request for interpretation support, we’d love to hear from you! Feel free to reply to this message or add agenda items to *the document here* <https://etherpad.wikimedia.org/p/language-community-meeting-may-2025>. Also, we wanted to highlight that the 7th edition of the *Language & Internationalization newsletter (April 2025)* is available here: *Wikimedia Language and Product Localization/Newsletter/2025/April* <https://www.mediawiki.org/wiki/Special:MyLanguage/Wikimedia_Language_and_Pr…>. This newsletter provides updates from the January–March 2025 quarter on new feature development, improvements in various language-related technical projects and support efforts, details about community meetings, and ideas for contributing to projects. To stay updated, you can subscribe to the newsletter on its wiki page: *Wikimedia Language and Product Localization/Newsletter* <https://www.mediawiki.org/wiki/Special:MyLanguage/Newsletter:Language_and_I…> . Would you be interested in contributing to the technical workaround language development? There is a newcomer-friendly core namespace-related task waiting for your contribution: *T391725* <https://phabricator.wikimedia.org/T391725>. We look forward to your ideas and participation at the Language Community Meeting, see you there! Oscar Language Diversity Hub

1 0

Beta Cluster wikis blocking IP ranges in response to aggressive bots
by Bryan Davis 24 Apr '25

24 Apr '25

I just wanted to give folks a heads up that in response to a few traffic storms in the Beta Cluster (deployment-prep CLoud VPS project) we have started using the very coarse protection of blocking IP ranges. These blocks are being applied at the Beta Cluster CDN edge where we have Varnish configuration that can discard traffic based on a list of CIDR ranges. The ranges blocked at any point in time should be visible in the deployment-prep project's Hiera configuration that is logged in the cloud/instance-puppet.git repo. [0] The hardly scientific process of choosing what to block so far has been done with processes like the one documented at https://phabricator.wikimedia.org/T392003. Hashar came up with a shell one-liner to count requests by IP address or IP address prefix depending on the regex provided. We then take the top addresses produced by that log filtering and perform a `whois` lookup to find the associated IP address allocation. The CIDR blocks associated with the allocation are then put into hiera config, a Puppet run is forced, and Varnish is restarted. Repeat as necessary to get to a reasonable rate of requests passing through Varnish to the backing MediaWiki instances where we are examining the logs. If you feel that you have legitimate traffic for the Beta Cluster to handle that has gotten swept up in one of these blocks, please reach out by filing task on the #beta-cluster-infrastructure Phabricator board. [1] If you think working to make this process of blocking easier or unnecessary sounds like a fun project I would love to chat more. Hit me up via email, libera.chat irc, or on-wiki with your ideas. [0]: https://gerrit.wikimedia.org/r/plugins/gitiles/cloud/instance-puppet/+/refs… [1]: https://phabricator.wikimedia.org/tag/beta-cluster-infrastructure/ Bryan -- Bryan Davis Wikimedia Foundation Principal Software Engineer Boise, ID USA [[m:User:BDavis_(WMF)]] irc: bd808

8 13

FYI: Edge Uniques
by Brandon Black 24 Apr '25

24 Apr '25

Hi everyone, If you follow any technical Wikimedia news, you might have read about this in Tech News or on Diff already, but in case you missed it: The Wikimedia Foundation is working on a system called Edge Uniques which will enable A/B testing, help mitigate DDoS attacks, and eventually give better visitor metrics. We’re doing this by adding a first-party cookie named "WMF-Uniq" which is handled *only* on our CDN edge servers directly. This cookie contains a randomly-generated unique identifier and a few bits of minimal metadata about site visit history. We've explicitly designed this system such that we do *not* need to or intend to store these cookies or their identifiers in any databases or logs anywhere on our servers, or forward them to any other complex parts of our internal server-side infrastructure where the risks of accidental leakage or storage might be higher. It's a fairly unique system, and one that we've tried to design for maximal privacy preservation and data minimization for Wikimedians while also meeting our needs around both A/B testing of reader-oriented features and helping to control the server load from botnets of various kinds with resource-abusive patterns. The A/B testing portion of this design can record relevant, specific, pre-defined metrics into our analytics databases for those agents selected for testing (e.g. "an agent in Test123/GroupA clicked the new blue button"), but these metrics records use a temporary, per-experiment derivative identifier created by a one-way hash, making them non-reversible back to the original cookie identifiers. You can read more details on Meta: https://meta.wikimedia.org/wiki/Edge_Uniques If you want to talk to us about this, we’re happy to discuss it on the project talk page: https://meta.wikimedia.org/wiki/Talk:Edge_Uniques We’re also hosting an office hours/community call to answer questions or discuss the topic further on April 29, 14:00 UTC. See more info here: https://meta.wikimedia.org/wiki/Edge_Uniques#Next_steps -- Brandon Black Principal Site Reliability Engineer, SRE Traffic Team Wikimedia Foundation

1 0

Several database changes happening in the coming months
by Amir Sarabadani 24 Apr '25

24 Apr '25

Hello, in the next coming months, these changes will happen in databases and the infrastructure. And it might affect you if you rely on them in your tools or queries. This list is ordered based on how soon the change will happen. We understand that updating your tools and systems can be time consuming, hence we are giving an advanced notice. I truly apologize for the inconvenience but many of these changes are needed to keep the site running smoothly. Image table redesign Around fourteen years after the creation of T28741 <https://phabricator.wikimedia.org/T28741>, we are implementing the changes described therein. Currently, every current version of an image has a row in the image table and if there are older versions of that file, those rows could be found in the oldimage table. These two tables (image and oldimage) will be dropped in around two months. The replacement will be two main tables: file and filerevision. Every file will have a row in the file table describing the name and the type. Every version of the file (current and old) will have a row in filerevision describing the file-specific information such as its size or the hash of the file, similar to the existing distinction between pages and revisions. Another improvement is that every file and file revision will get a unique auto increment id simplifying many operations and queries. You can check T28741 <https://phabricator.wikimedia.org/T28741> for more information. The new tables are already accessible in wikireplicas but the data hasn’t been fully migrated yet. Term store split out of wikidata’s database Wikidata’s database has been growing too fast and we need to move the term store (tables starting with wbt_) to a dedicated cluster to allow growth and improve wikidata’s performance by utilizing cache locality. The new section will be called x3 and you will be able to access it in wikireplicas but this also means you won’t be able to join these tables with the rest of wikidata’s database (such as page table) since they will be residing in two physically separate servers that also means most of your queries to wikidata’s database (and term store) will become faster. We are aiming for the switch to happen in three months’ time. You can follow the work in T351820 <https://phabricator.wikimedia.org/T351820>. Additionally, wb_type table will be dropped and the mapping will be hard-coded in the code instead. See gerrit:1110810 <https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1110810> for more details. This helped us simplify a lot of Wikibase code (example <https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1110720>). Categorylinks normalization Categorylinks is the next table in the series of links tables being normalized via the linktarget table (parent ticket <https://phabricator.wikimedia.org/T300222>, RFC <https://phabricator.wikimedia.org/T222224>). Similar to templatelinks and pagelinks tables, cl_to will be dropped and instead the new field cl_target_id will point to lt_id in the linktarget table. We will also drop the cl_collation field and replace it with cl_collation_id which will point to the collation_id field on the new table we are introducing called collation. We are aiming to get this fully done by the end of the next quarter (end of June 2025) but it depends on how fast the migration script can operate and that’s outside of our control. You can follow the work in T299951 <https://phabricator.wikimedia.org/T299951>.It’s worth noting that after this migration is done, we will start working on the imagelinks table. Thank you -- *Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation <https://wikimediafoundation.org/>

1 1

Tech News 2025, week 17
by Nick Wilson (Quiddity) 23 Apr '25

23 Apr '25

Latest *tech news <https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News>* from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations <https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/2025/17> are available. *Updates for editors* - Wikifunctions <https://www.wikifunctions.org/wiki/Special:MyLanguage/Wikifunctions:Main_Pa…> is now integrated with Dagbani Wikipedia <https://en.wikipedia.org/wiki/dag:Sol%C9%94%C9%A3u> since April 15. It is the first project that will be able to call functions from Wikifunctions <https://www.wikifunctions.org/wiki/Special:MyLanguage/Wikifunctions:Introdu…> and integrate them in articles. A function is something that takes one or more inputs and transforms them into a desired output, such as adding up two numbers, converting miles into metres, calculating how much time has passed since an event, or declining a word into a case. Wikifunctions will allow users to do that through a simple call of a stable and global function <https://www.wikifunctions.org/wiki/Special:MyLanguage/Wikifunctions:Catalog…>, rather than via a local template. [1] <https://www.wikifunctions.org/wiki/Special:MyLanguage/Wikifunctions:Status_…> - A new type of lint error has been created: Empty headings <https://meta.wikimedia.org/wiki/Special:LintErrors/empty-heading> ( documentation <https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Lint_errors/empty-he…>). The Linter extension <https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Extension:Linter>'s purpose is to identify wikitext patterns that must or can be fixed in pages and provide some guidance about what the problems are with those patterns and how to fix them. [2] <https://phabricator.wikimedia.org/T368722> - [image: Recurrent item] View all 37 community-submitted tasks that were resolved last week <https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/Recently_resol…> . *Updates for technical contributors* - Following its publication on HuggingFace, the "Structured Contents" dataset, developed by Wikimedia Enterprise, is now also available on Kaggle <https://enterprise.wikimedia.com/blog/kaggle-dataset/>. This Beta initiative is focused on making Wikimedia data more machine-readable for high-volume reusers. They are releasing this beta version in a location that open dataset communities already use, in order to seek feedback, to help improve the product for a future wider release. You can read more about the overall Structured Contents project <https://enterprise.wikimedia.com/blog/structured-contents-snapshot-api/#ope…>, and about the first release that's freely usable <https://enterprise.wikimedia.com/blog/structured-contents-wikipedia-infobox/> . - There is no new MediaWiki version this week. *Meetings and events* - The Editing and Machine Learning Teams invite interested volunteers to a video meeting to discuss Peacock check <https://www.mediawiki.org/wiki/Special:MyLanguage/Edit_check/Peacock_check>, which is the latest Edit check <https://www.mediawiki.org/wiki/Special:MyLanguage/Edit_check> that will detect "peacock" or "overly-promotional" or "non-neutral" language whilst an editor is typing. Editors who work with newcomers, or help to fix this kind of writing, or are interested in how we use artificial intelligence in our projects are encouraged to attend. The meeting will be on April 28, 2025 <https://www.mediawiki.org/wiki/Special:MyLanguage/Editing_team/Community_Co…> at 18:00–19:00 UTC <https://zonestamp.toolforge.org/1745863200> and hosted on Zoom. *Tech news <https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News> prepared by Tech News writers <https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/Writers> and posted by bot <https://meta.wikimedia.org/wiki/Special:MyLanguage/User:MediaWiki_message_d…> • Contribute <https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News#contribute> • Translate <https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/2025/17> • Get help <https://meta.wikimedia.org/wiki/Tech> • Give feedback <https://meta.wikimedia.org/wiki/Talk:Tech/News> • Subscribe or unsubscribe <https://meta.wikimedia.org/wiki/Global_message_delivery/Targets/Tech_ambass…>.*

5 7

Struggling with Online Classes? Here's a Reliable Help Option!
by course fpx 22 Apr '25

22 Apr '25

Hey everyone, I’ve noticed a lot of students (including myself) struggling with the pressure of online classes, deadlines, and quizzes — especially with platforms like Capella FlexPath, WGU, and others. If you're overwhelmed, there’s a service I recently came across called Online Classes Help. They assist with everything from discussion posts and assignments to full course completion. Super helpful for those juggling jobs or other responsibilities! Whether you need one-time help or ongoing support, this could really reduce your stress and help you maintain a good GPA. Just make sure to use it ethically — as a support tool, not a shortcut! Has anyone else tried such services? Would love to hear your experiences. Cheers! fpr more info :https://coursefpx.com/online-class-help/

1 0

Mini RFC: Rename ConvertibleTimestamp class to Timestamp
by Krinkle 19 Apr '25

19 Apr '25

https://gerrit.wikimedia.org/r/c/mediawiki/libs/Timestamp/+/1137473 I'd like to make this library more appealing for direct use in MediaWiki. The current lengthy name of its primary entrypoint is imho off-putting, and implies a working model that we may have originally envisioned but is not how it works in practice. Rather than creating and holding object references that one can convert, the API has been much improved and simplified over the years to be stateless and working with just scalar values in, and scalar values out. The versatile parsing features and mocking capabilities are probably as significant nowadays if not more so, than the fact that it can return/convert several different string formats. As such, I suggest we rename the class to plain "Timestamp". As before, the place where conversion happens from caller perspective, is the Timestamp::convert() method, which is imho well-named. *== Example: Convert a timestamp ==* // Traditional MediaWiki class FooBar { public function execute( $a, $data ) { if ( $a ) { $touched = *wfTimestamp*( TS_UNIX, $data->getTime() ); } } } // Middle-school MediaWiki use MediaWiki\Utils\MWTimestamp; class FooBar { public function execute( $a, $data ) { if ( $a ) { $touched = *MWTimestamp::convert*( TS_UNIX, $data->getTime() ); } } } // Future A use Wikimedia\Timestamp\ConvertibleTimestamp; class FooBar { public function execute( $a, $data ) { if ( $a ) { $touched = *ConvertibleTimestamp::convert*( TS_UNIX, $data->getTime() ); } } } // Future B use Wikimedia\Timestamp\Timestamp; class FooBar { public function execute( $a, $data ) { if ( $a ) { $touched = *Timestamp::convert*( TS_UNIX, $data->getTime() ); } } } ``` *== Example: Get current time ==* Here the name seems even more out of place, as there is not only no convertible object in sight, there is also no conversion intent as far as the caller is concerned. $now = *wfTimestamp*( TS_MW ); $now = *MWTimestamp::now*( TS_MW ); $now = *ConvertibleTimestamp::now*( TS_MW ); $now = *Timestamp::now*( TS_MW ); Like with T253461: Liberate the @ for AtEase <https://phabricator.wikimedia.org/T253461>, I would recommend this be a low-key and smooth migration. No disruption, no en-mass patches, no deprecation, and no planned removal. Just a simple class alias. If and when in a few years there is a good reason for a semver-major release to wikimedia/timestamp, we can revisit this at that time. -- Timo Tijhof

2 1

MediaWiki 1.44-alpha will be branched as a beta on 22-04-2025
by Mateus Santos 17 Apr '25

17 Apr '25

Hey all, This is a quick note to highlight that in three weeks' time, the REL1_44 branch will be created for MediaWiki core and each of the extensions and skins in Wikimedia git, with some (the 'tarball') included as sub-modules of MediaWiki itself[0]. This is the first step in the release process for MediaWiki 1.44, which should be out in June 2025, approximately six months after MediaWiki 1.43. The branches will reflect the code as of the last 'alpha' branch for the release, 1.44.0-wmf.26, which will be deployed to Wikimedia wikis in the week beginning 20 April 2025 for MediaWiki itself and those extensions and skins available there. After that point, patches that land in the main development branch of MediaWiki and its bundled extensions and skins will be instead be slated for the MediaWiki 1.44 release unless specifically backported[1]. If you are working on a new feature that you wish to land for the release, you now have a few days to finish your work and land it in the development branch; feature changes should not be backported except in an urgent case. If your work might not be complete in time, and yet should block release for everyone else, please file a task against the `mw-1.44-release` project on Phabricator.[2] If you have tickets that are already tagged for `mw-1.44-release`, please finish them, untag them, or reach out to get them resolved in the next few weeks. We hope to issue the first release candidate, 1.44.0-rc.0, two weeks after the branch point, and if all goes well, to release MediaWiki 1.44.0 a few weeks after that. [0]: <https://www.mediawiki.org/wiki/Bundled_extensions_and_skins> [1]: <https://www.mediawiki.org/wiki/Backporting_fixes> [2]: <https://phabricator.wikimedia.org/tag/mw-1.44-release/>

1 1

Excited to Contribute to Wikimedia Foundation
by nidha ahmed 17 Apr '25

17 Apr '25

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.

3 2

Database dumps
by Byrial Jensen 17 Apr '25

17 Apr '25

Until some weeks ago http://dumps.wikimedia.org/backup-index.html used to show 4 dumps in progress at the same time. That meant that new database dumps normally was available within about 3 weeks for all databases except for enwiki and maybe dewiki where the dump process due to size took longer time. However the 4 dumps processes at one time become 3 some weeks ago. And after massive failures at June 4, only one dump has been in progress at the same time. So at the current speed it will take several months to come thru all dumps. Is it possible to speed up the process again using several dump processes at the same time? Thank you, Byrial

3 2

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