Wikitech-l November 2025

wikitech-l@lists.wikimedia.org

20 participants
20 discussions

Upcoming Language Community Meeting (November 28th, 16:00 UTC), Newsletter, and Technical Contribution Tasks
by Srishti Sethi 28 Feb '26

28 Feb '26

Hello everyone! We're excited to announce that the next Language Community Meeting is happening soon - on November 28th at 16: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. For example, in our upcoming meeting, we plan to hear from contributors of the Wikitongues project and Fante Wikimedia Community. 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-nov-2025>. Also, we’d like to highlight that the 9th edition of the Language & Internationalization Newsletter (October 2025) <https://www.mediawiki.org/wiki/Wikimedia_Language_and_Product_Localization/…> is now available. This newsletter provides updates from the July–September 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 <https://www.mediawiki.org/wiki/Newsletter:Language_and_Internationalization…> on its wiki page. Are you interested in contributing to the technical work around language development? See a curated list of technical contribution tasks here: T407935 <https://phabricator.wikimedia.org/T407935>. We look forward to your ideas and participation at the Language Community Meeting. See you there! Cheers, Srishti *Srishti Sethi* Senior Developer Advocate Wikimedia Foundation <https://wikimediafoundation.org/>

1 3

User style to reduce Gerritbot comments on Phabricator
by Bartosz Dziewoński 09 Jan '26

09 Jan '26

Do your eyes glaze over when trying to make sense of Phabricator tasks with a long and troubled history of patches? Do you struggle to find the real people in the sea of automated bot comments? I've made myself a user style to compact the Gerritbot comments on Phabricator. You might like it too: https://userstyles.world/style/13140/wikimedia-phabricator-reduce-gerritbot… (See screenshots and installation instructions there.) -- Bartosz Dziewoński

10 23

CI: disabling recursion on MediaWiki extension dependencies
by Antoine Musso 26 Nov '25

26 Nov '25

Hello, On CI, if your MediaWiki extension has any dependencies, those are processed recursively. As of today, I am disabling recursion on some extensions when the CI jobs are known to pass without it. Most extensions have a small set of hard requirements (via extension.json <https://www.mediawiki.org/wiki/Manual:Extension_registration#Requirements_(…>). As developers added integration tests (which is great) more soft dependencies have been added to the tree. Due to recursion, CI can clone up to 65 extensions and, since it runs every single tests, this cause build runtime to be fairly long. Timo Tijhof wrote a very nice problem statement on https://phabricator.wikimedia.org/T389998. For the last few weeks I have worked on the problem to make it possible to disable recursion and went to patch several extensions to allow the removal of some dependencies. The recursion is disabled via a recurse boolean parameter which can be checked at https://gerrit.wikimedia.org/g/integration/config/+/refs/heads/master/zuul/… CI adds to the builds a MW_ZUUL_RECURSE parameter ("true" or "false") to expose whether recursion is enabled. You can find it in the builds parameters, for example: https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php81/lastSuc… Although I have verified the jobs still pass, there might be issues with tests from dependencies due to their own dependencies no more being cloned. In this case, those tests should be skipped. With PHPUnit this can be done using: $this->markTestSkippedIfExtensionNotLoaded( <dependency> ); For example WikimediaMessages <https://www.mediawiki.org/wiki/Extension:WikimediaMessages> (which holds Wikimedia specific localization messages) depends on the cldr <https://www.mediawiki.org/wiki/Extension:CLDR> extension. WikimediaMessages is also used as a dependency by multiple extensions which do not require cldr nor do any integration testing with cldr. When recursion is disabled, those extensions no more have cldr added and that would cause WikimediaMessages test to fail. I have thus marked the test to be skipped: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaMessages/+/1…. When CI runs for WikimediaMessages, cldr is cloned (since it is a direct dependency) and the test does run. As part of disabling recursion, there might be issues due to a missing class/extension. In this case, please file a task in Phabricator <https://phabricator.wikimedia.org/maniphest/task/edit/form/1/> against project #ci-test-error and as a subtask of T389998 <https://phabricator.wikimedia.org/T389998> mentioning the Gerrit change, the values of MW_ZUUL_RECURSE and EXT_DEPENDENCIES and a copy of the error found in the build console. cheers, Antoine "hashar" Musso Wikimedia Release Engineering

1 0

Tech News 2025, week 48
by Sandister Tei 25 Nov '25

25 Nov '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/48> are available. *Updates for editors* - Last week, the Wikimedia Search Team <https://www.mediawiki.org/wiki/Special:MyLanguage/Wikimedia_Search_Platform> recreated the "DWIM" (Do What I Mean) gadget functionality server-side, for Russian and Hebrew Wikipedias. This feature adds cross-keyboard suggestions to the standard search-box suggestions. For example, searching for *cxfcnmt* on Russian Wikipedia will now add suggestions for *счастье* ("happiness") that the user probably intended. They plan to enable this feature for other Russian and Hebrew wikis this week. [1] <https://phabricator.wikimedia.org/T408734> - Later this week, users of the "Improved Syntax Highlighting" beta feature <https://meta.wikimedia.org/wiki/Special:Preferences#mw-prefsection-betafeat…> will have syntax highlighting available in DiscussionTools <https://www.mediawiki.org/wiki/Special:MyLanguage/Help:DiscussionTools>. This requires that the "Enable editing tools in source mode" preference be set. [2] <https://phabricator.wikimedia.org/T407918> - Campaign events extension <https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Extension:CampaignEv…> – the set of tools for coordinating events and other on-wiki collaborations has now been deployed to all Wikimedia wikis. A new feature known as Collaborative contribution <https://meta.wikimedia.org/wiki/Special:MyLanguage/CampaignEvents/Collabora…> to help organizers and participants see the impact of activities has also been added. Join the upcoming learning session <https://meta.wikimedia.org/wiki/Special:MyLanguage/Event:Connection_learnin…> to see the new feature in action and share your feedback. - View all 24 community-submitted tasks that were resolved last week <https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/Recently_resol…>. For example, the bug which stopped CodeReviewBot from working, has now been fixed. [3] <https://phabricator.wikimedia.org/T410417> *Updates for technical contributors* - Users of Wikimedia API can join a usability study to help validate the new design of Wikimedia REST API sandboxes. Interested participants should fill the recruitment survey <https://wikimediafoundation.limesurvey.net/487662>. [4] <https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…> - The MediaWiki Interfaces team is deprecating XSLT stylesheets within the Action API. Support for format=xml*&xlst={stylesheet}* will be removed from Wikimedia projects by the end of November, 2025. In addition, it will soon be disabled by default in MediaWiki release versions: v1.43 (LTS), v1.44, and v1.45. Support for XSLT stylesheets will be fully removed from MediaWiki v1.46 (expected to release between April and May 2026). [5] <https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…> - The WDQS legacy endpoint (query-legacy-full.wikidata.org) will be decommissioned at the end of December 2025, and finally closed down on 7th January 2026. After this date, users should expect requests to query.wikidata.org that require the full graph to fail or return invalid results if they are not rewritten to use SPARQL federation. The team encourages users to ensure that tools and workflows use the supported WDQS endpoints (https://query.wikidata.org/ - Main graph or https://query-scholarly.wikidata.org/ - Scholarly graph). For support with migrating use cases, please review the Data Access <https://www.wikidata.org/wiki/Special:MyLanguage/Wikidata:Data_access> and Request a Query <https://www.wikidata.org/wiki/Wikidata:Request_a_query> pages for details and assistance on alternative access methods. - Detailed code updates later this week: MediaWiki <https://www.mediawiki.org/wiki/MediaWiki_1.46/wmf.4> *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/48> • 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…>.*

1 0

Unified mobile routing: Mobile pages without redirect
by Krinkle 25 Nov '25

25 Nov '25

TLDR: Mobile devices will receive the mobile version directly on the standard domain, instead of via a redirect to the mobile subdomain. The change is live in the Beta Cluster and on test wikis, and expected to follow a train-like rollout over the next few weeks. Today, when you visit a link to a wiki (like en.wikipedia.org), the server responds in one of two ways: a desktop page, or a redirect to the equivalent mobile URL (like en.m.wikipedia.org). This mobile URL in turn serves the mobile version of the page from MediaWiki. Our CDN operates this way since 2011, when we enabled MobileFrontend by default. Diagram: Unified mobile routing - before and after <https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsettin…> This redirect causes a number of problems, [2] such as: • User experience: Links shared by mobile users always display in mobile mode instead of the mode for your device, even after opt-out. • Site performance: Every Google Search result click is delayed by the redirect before displaying the article. • SEO: There is a conflict in our link graph because standard URLs redirect to mobile, and mobile sets a canonical pointer back to the standard URL. This de-indexes or mis-indexes pages in Google. T400022 <https://phabricator.wikimedia.org/T400022> • Infrastructure cost: MediaWiki sends twice as many purges to our CDN infrastructure. • Technical debt and known issues (e.g. incompatibility with OAuth). [3] Over the next few weeks, the CDN will serve the mobile version directly, without first redirecting the browser to the mobile subdomain. What is not changing • Backend code may detect mobile mode via `MobileContext->shouldDisplayMobile()`. • Frontend code may detect mobile mode via `mw.config.get('wgMFMode')`. [4] • Third-party MediaWiki sites. This is a WMF configuration change only. • Mobile requests to MediaWiki (identical HTTP host and headers). • Existing mobile URLs continue to work. • The "Desktop" opt-out footer link. • The speed of light. Backend requests unchanged The mobile subdomain on WMF wikis is only recognised by Varnish (Wikimedia CDN). Varnish strips this "m" from the domain, activates MobileFrontend, and forwards the request to MediaWiki with the standard domain. [1] This means MediaWiki core and extensions know how to handle mobile requests on the standard domain, because that's how it already works. It also means that the change is not observable (through supported means) by backend feature code in MediaWiki, because the mobile subdomains don't exist there. What should I test? If your gadget or MediaWiki extension does not vary its behavior for mobile, or detects mobile mode using the supported mechanism listed above, then you're all set. Note that Minerva-specific or mobile-specific code in a MediaWiki extension is naturally compatible with unified mobile routing, if it was tested locally or in CI. When you install Minerva (and optionally MobileFrontend) in your dev environment, they operate without a mobile subdomain by default. • There is (probably) no mobile domain in your local dev environment. • There is no mobile domain in Patch demo. • There is no mobile domain in CI. This infrastructure change aligns WMF production with how MediaWiki and MobileFrontend work by default. This decreases the potential for bugs we have today that can be exclusively found in production (via the mobile subdomain), and resolves a backlog of existing known issues. [3] Unsupported checks in frontend code If a JavaScript-based feature contains a hardcoded `m.` hostname check, then this will no longer match in the future. The most likely place to find hardcoded `m.` checks is in a gadget or user script that changes its appearance or logic for mobile pages. Detecting the mobile mode in this way is unsupported and should be replaced with a supported mechanism <https://phabricator.wikimedia.org/T390923> instead. [4] An audit in April 2025 found there were 2 WMF-deployed extensions using this, which were confirmed to fallback gracefully or have since been adjusted. [5] Where can I test? The new unified mobile routing is live on these wikis: • Beta Cluster at https://beta.wmcloud.org • test wikis at https://test.wikipedia.org and https://test.wikidata.org • https://wikitech.wikimedia.org • https://office.wikimedia.org • https://www.mediawiki.org For other production wikis, such as en.wikipedia.org, you can preview the change today by adding `?useformat=mobile` to a URL. This activates MobileFrontend on the standard domain, like it would in the future. For example: https://en.wikipedia.org/wiki/Banana?useformat=mobile. The timeline <https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsettin…> spans several weeks and should not require dedicated testing. If you're unsure, you can test on the pilot wikis above, or in production via the `useformat=mobile` parameter. f you find a bug with mobile toggling or another regression, please report a bug to Phabricator. If you have questions or need help with a gadget or user script, please reach out on the talk page <https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Mobile_domain_suns…>. -- Timo Tijhof 🔗 Read or share this post on the web via: https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsettin… [1]: Diagram of mobile routing before and after <https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsettin…> [2]: Problem statement and analysis on mediawiki.org <https://www.mediawiki.org/wiki/Requests_for_comment/Mobile_domain_sunsettin…> [3]: Known issues listed in the Phabricator task <https://phabricator.wikimedia.org/T214998> [4]: Remember that mobile detection should be rare in frontend code, because most differences are between skins (Minerva vs another skin) and not MobileFrontend. [5]: Audit of unsupported m-dot checks in JavaScript <https://phabricator.wikimedia.org/T390923>

2 2

Deprecation Announcement: XSLT Stylesheets in Action API
by Halley Coplin 22 Nov '25

22 Nov '25

Hello, technical contributors! The MediaWiki Interfaces team is deprecating XSLT stylesheets within the Action API. Support for the format=xml&*xlst={stylesheet}* will be removed from Wikimedia projects by the end of November, 2025. In addition, it will soon be disabled by default in MediaWiki release versions: v1.43 (LTS), v1.44, and v1.45. Support for XSLT stylesheets will be fully removed from MediaWiki v1.46 (expected to release between April and May 2026). *=== Why are we deprecating and removing this capability? ===* Support for XSLT is generally being removed from browsers, due to a high rate of security risks and declining usage. Chrome is officially starting the XSLT deprecation cycle <https://developer.chrome.com/docs/web-platform/deprecating-xslt>in November 2025, with full removal expected by November 2026. Other browsers are expected to follow. To ensure that we are not including a feature that will no longer be supported by browsers, we decided to end support, as well. *=== What is the impact? === * There is currently very limited adoption of this feature across Wikimedia projects, with usage limited to a handful of gadgets that currently rely on this capability. We are engaging with some of the key gadget owners directly, so they are aware of the change and can adjust or remove lesser used features accordingly. We also recognize that some third parties may rely on XSLT stylesheets. In this case, we encourage consumers to find alternative solutions as soon as possible, given the end of XSLT support goes beyond the scope of MediaWiki. I encourage tool developers, gadget authors, and third party users to engage directly if you have questions, concerns, or if this change may block your ability to upgrade to future versions in a timely manner. Thanks, Halley *Halley Coplin* (she/her) Sr. Product Manager, MediaWiki Interfaces Wikimedia Foundation <https://wikimediafoundation.org/>

1 0

FTP (?)
by Hipparchiaa 21 Nov '25

21 Nov '25

Madam, Sir, I am writing to you after being advised to do so. I am the email address behind the Aristoxène account on Wikimedia projects, and I have started several projects to archive/publish historical documents concerning the history of the anarchist movement. In this capacity, I have partnered with another historian of the movement who possesses an immense archival database that he has fully agreed to contribute and share to Commons. I have [started doing this](https://commons.wikimedia.org/wiki/Category:Collection_of_Archives_An…, but I was quickly confronted with a major issue: either I maintain the original quality of the documents (so a police file of 1,000 pages, which is not that rare, is around 2 GB) but in that case I am capped by Commons and the upload speed is extremely slow (it takes +10 hours to upload); or I compile it into DjVu and in that case it is much easier and faster, but the quality of the documents (which are already handwritten and not always very easy to read even in good quality) is severely impacted, making them very difficult to use. I discussed this with a friend who does a lot of archiving work, and he told me that it would be entirely possible to request an 'FTP' at this email address; I don't know what that means, but here I am doing it—if I could upload faster it would be incredible, because right now I have about 600 GB of documents and that would take five months non-stop. Cordially, Aristoxène Sent with [Proton Mail](https://proton.me/mail/home) secure email.

2 2

MediaWiki 1.45.0-rc.0 is ready for testing
by Mateus Santos 21 Nov '25

21 Nov '25

I'm pleased to announce the immediate availability of MediaWiki 1.45.0-rc.0, the first release candidate for 1.45.0. Download links are at the end of the e-mail. The tag has been signed and pushed to Git. This is not a final release, and should not be used for production websites. Known issues are tracked in Phabricator on the release workboard [1]. As with every release of MediaWiki, a large number of changes have landed in the six months of development (over 2300 commits since 1.44.0 was cut), and you should read over the preliminary release notes as part of assuring yourself of areas that may have issues with your configuration, your skins, and/or your extensions. As always, please try out the release candidate in a test environment and do report any issues that you discover. Please use the #MW-1.45-Release [2] tag in Phabricator when reporting issues specific to this release, to make sure that we find them as quickly as possible. It is expected that MediaWiki *1.45 will become final in 2 weeks*. This date may slip if blockers are identified. Preliminary release notes: https://gerrit.wikimedia.org/g/mediawiki/core/+/REL1_45/RELEASE-NOTES-1.45 Open Bugs: [1] https://phabricator.wikimedia.org/tag/mw-1.45-release/ Bug report form: [2] https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tags=MW-1.45-… ********************************************************************** Download: https://releases.wikimedia.org/mediawiki/1.45/mediawiki-1.45.0-rc.0.tar.gz https://releases.wikimedia.org/mediawiki/1.45/mediawiki-1.45.0-rc.0.zip Download without bundled extensions: https://releases.wikimedia.org/mediawiki/1.45/mediawiki-core-1.45.0-rc.0.ta… https://releases.wikimedia.org/mediawiki/1.45/mediawiki-core-1.45.0-rc.0.zip GPG signatures: https://releases.wikimedia.org/mediawiki/1.45/mediawiki-core-1.45.0-rc.0.ta… https://releases.wikimedia.org/mediawiki/1.45/mediawiki-core-1.45.0-rc.0.zi… https://releases.wikimedia.org/mediawiki/1.45/mediawiki-1.45.0-rc.0.tar.gz.… https://releases.wikimedia.org/mediawiki/1.45/mediawiki-1.45.0-rc.0.zip.sig Public keys: https://www.mediawiki.org/keys/keys.html

1 0

Phabricator improvements
by Andre Klapper 20 Nov '25

20 Nov '25

I am excited to announce that this is an exciting announcement. Today the Wikimedia Release Engineering Team deployed a larger software upgrade of https://phabricator.wikimedia.org You now better enjoy * Performance improvements: - Global fulltext Search ignores data of uninstalled Phab apps - Embedded full size image files are lazy loaded - Using DNS preconnect for our separate file domain - Faster rendering of Project Burndown tabular reports * Search user interface: - "Advanced Search" renamed to Global Search and application search - Global Search Scope dropdown: "Current Application" replaced by the actual app name; no more such option when the app does not support global fulltext search - Maniphest Task Search does not anymore show unused "Packages" and "Owners" when using typeahead in the "Subscribers" search field - Ctrl+Return in text boxes opens search results in a new tab * User Profile pages: - New "Authored Tasks" one-click menu item in sidebar - Less ambiguous menu item names in sidebar - Support for images in WebP format as avatars - (admins only): One-click menu item to view Activity Log of user - (admins only): User's Two-Factor Auth status shown on profile page * Project Workboards: - Those numbers in workboard column headers have now tooltips - Archived projects are now strike-through in navigation breadcrumbs - Automated Column Triggers: Allow setting the user who performs the move as task assignee - Thinner scrollbars in Firefox on Windows - Importing columns: No more crash when typeahead querying projects and search string is not a project name prefix - The "Move Tasks" action now requires "Can Bulk Edit Tasks" rights * Herald automated actions: - New condition "Acting user's projects" available - No more "Unknown Object (????)" for custom field values in editor * General text input: - No more text suddenly disappearing when writing {{#something:}} - Stripped surrounding whitespace when entering project or task titles - Support for "size=thumb" parameter when embedding video files * Conduit API: - Support search select fields as constraints, e.g. "Group By" in maniphest.search, project status in project.search, status and hosted in diffusion.repository.search - Improved documentation of types in transaction.search * User Preferences: - Email: No more useless "Audits" section (we uninstalled that app) - External Accounts: Shows tooltips for buttons - Multi-Factor Auth: Explains consequences of adding a second factor * Projects: - Profile images: Show maximum picture dimensions at uploading - No more "set this color to Red" message editing archived projects - No more 404 error on URLs with an alternative hashtag of a milestone * Project Report Charts: - Rotated x-axis labels for better readability - Improved line colors * Files: - Support rendering images in WebP format - List of uploads includes the timestamp, not only the date * Mobile: Support zooming on pages (e.g. when looking at image files) * Mobile: Detection of Firefox on Android (to adjust content width) * Tokens: Allow filtering given tokens by token types * Wikibugs IRC bot: Report the color of milestones correctly * (admins only) Allow changing email of bot and mailing list accounts * Numerous crasher fixes * Some accessibility improvements (ARIA labels, titles, etc) * Cleaner CSS (less noise in your browser's Developer Tools' console) Our Downstream dependency trees of tasks are at https://phabricator.wikimedia.org/T386558 and https://phabricator.wikimedia.org/T393840 I'd like to thank the Wikimedians BlankEclair, mainframe98, MatmaRex, pppery, taavi, valerio.bozzolan, xtex, who contributed patches to the upstream project at https://we.phorge.it. (Hope I forgot nobody?) As usual, if you have comments or questions about Phab, please bring them up on https://www.mediawiki.org/wiki/Talk:Phabricator/Help ! Cheers, andre (on behalf of the Wikimedia Release Engineering Team) -- Andre Klapper (he/him) | Bugwrangler https://blogs.gnome.org/aklapper/

3 3

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

20 Nov '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/

2 2

2026

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