Wikitech-l September 2025

wikitech-l@lists.wikimedia.org

19 participants
24 discussions

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

24 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

Phabricator improvements
by Andre Klapper 19 Nov '25

19 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 19 Nov '25

19 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

Upcoping Gerrit Maintenance - Monday, 6 Oct 2025, 12:00–13:00 UTC
by Arnaud Bran 13 Oct '25

13 Oct '25

Hello, We will perform maintenance on Gerrit on *Monday, October 6*, from *12:00 to 13:00 UTC*. During this window, we expect a *~20 minutes* write outage while we switch over Gerrit's service from the current primary (gerrit1003) to the spare host (gerrit2003). Since last time, we've added a few guardrails: - Local emergency backup on each instance. - All instances will be *read-only during the switchover *to protect data integrity. - Pre- and post-switch checks to verify everything is in the expected state. As before, we’ll perform the switchover *live with Release Engineering*. This operation will allow us to unblock a few things: - System daemon user: *gerrit2 → gerrit (*T338470 <https://phabricator.wikimedia.org/T338470>) - *OS upgrade* (T392464 <https://phabricator.wikimedia.org/T392464>, T384595 <https://phabricator.wikimedia.org/T384595>)*, Java* (T392465 <https://phabricator.wikimedia.org/T392465>) version update and *Gerrit * (T379714 <https://phabricator.wikimedia.org/T379714>, T392448 <https://phabricator.wikimedia.org/T392448>) version update *Expected impact* - A ~20 minutes *read-only* window; reads (browsing, cloning, reviewing) should remain fine. Pushes, votes, comments, etc. will be blocked during that period - We’ll post start/end updates during the window. *Links* - Documentation: https://wikitech.wikimedia.org/wiki/Gerrit/Operations#Switch_over - Phabricator: https://phabricator.wikimedia.org/T387833 - Deployment Calendar: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20251006T1200 Thank you for your understanding. -- *Arnaud Bran* (he/him) Senior Site Reliability Engineer Wikimedia Foundation <https://wikimediafoundation.org/>

2 5

eqiad Wikikube kubernetes cluster upgrade to 1.31 and Toolhub downtime [Wed Oct 1st 2025 10:00-15:00 UTC]
by Clément Goubert 01 Oct '25

01 Oct '25

Hello everyone, Short version: We will be upgrading the eqiad Wikikube kubernetes <https://wikitech.wikimedia.org/wiki/Kubernetes/Clusters#WikiKube> cluster to 1.31 on Wednesday 2025-10-01 starting at 10:00 UTC <https://zonestamp.toolforge.org/1759312800>, ending at 15:00 UTC <https://zonestamp.toolforge.org/1759330800>. Toolhub will be down during this maintenance. If you are deploying services to the eqiad Wikikube kubernetes cluster: - Deployments will be unavailable during the maintenance. DO NOT DEPLOY. - SRE will redeploy all services - SRE will announce the end of maintenance, at which point the cluster will be usable again --- Object: Kubernetes upgrade to 1.31 Target: eqiad Wikikube cluster Maintenance window: 2025-10-01 10:00 <https://zonestamp.toolforge.org/1759312800>-15:00 <https://zonestamp.toolforge.org/1759330800> UTC Tracking task: Phabricator at ⚓T405703 Update wikikube eqiad to kubernetes 1.31 <https://phabricator.wikimedia.org/T405703> Operational channel: IRC #wikimedia-sre <https://web.libera.chat/gamja/?nick=Guest#wikimedia-sre>, announcements will be made to IRC #wikimedia-operations <https://web.libera.chat/gamja/?nick=Guest#wikimedia-operations> Operating team: SRE ServiceOps (contact IRC #wikimedia-serviceops <https://web.libera.chat/gamja/?nick=Guest#wikimedia-serviceops>) Impact: Users: - Toolhub will be down for the duration of the window. - No user impact for other services. Deployers: - Deployments to the target cluster will be unavailable. This includes MediaWiki backports and deployments. DO NOT DEPLOY. - The following deployment windows are cancelled: - Services: Citoid/Zotero 11:00 UTC <https://zonestamp.toolforge.org/1759316400> - UTC Afternoon Backport Window 13:00 UTC <https://zonestamp.toolforge.org/1759330800> - Wikifunctions Services UTC Afternoon 14:00 UTC <https://zonestamp.toolforge.org/1759327200> Process: All steps handled by SRE ServiceOps - Maintenance start is announced on #wikimedia-operations and as reply to this email chain - All deployments are stopped - SRE ServiceOps ensures all current versions of deployments can be safely deployed - Maintenance begins and should take a couple of hours - Toolhub downtime starts - Cluster is wiped and upgraded - Toolhub is redeployed first to minimize downtime - Toolhub downtime stops - SRE ServiceOps redeploys all target cluster services - Maintenance end is announced on #wikimedia-operations and as reply to this email chain - Deployments resume Rationale: The date was chosen for convenience as due to the data center switchover process <https://wikitech.wikimedia.org/wiki/Switch_Datacenter>, eqiad is currently fully depooled, receiving almost no traffic. eqiad is scheduled to be repooled on 2025-10-02 <https://zonestamp.toolforge.org/1759417200>, which would complicate the upgrade. With eqiad already drained, we expect no visible user impact. SRE ServiceOps will be checking that all services can be safely deployed before the maintenance, and will be redeploying all services before marking the cluster as usable. Deployers are not required to re-deploy their services, unless they have been informed to do so by SRE ServiceOps. During last week’s switchover <https://phabricator.wikimedia.org/T399891>, Toolhub remained in eqiad. This means that there will be an expected unavoidable small downtime of a few hours. To minimize Toolhub’s downtime, we will prioritize its redeployment during the initialization phase. Thank you for your understanding and support! If you have any questions regarding this process, please respond to this email, comment on Phabricator at ⚓T405703 Update wikikube eqiad to kubernetes 1.31 <https://phabricator.wikimedia.org/T405703>, or reach out directly to me (IRC nickname claime on #wikimedia-serviceops <https://web.libera.chat/gamja/?nick=Guest#wikimedia-serviceops>). On behalf of SRE ServiceOps, -- Clément 'claime' Goubert (they/them) Senior SRE Wikimedia Foundation

1 4

Talk to the Search Platform / Query Service Team—October 1, 2025
by Guillaume Lederrey 01 Oct '25

01 Oct '25

Hello all! The Search Platform Team usually holds an open meeting on the first Wednesday of each month. 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, October 1, 2025 Time: 15:00-16:00 UTC / 08:00 PST / 11:00 EST / 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 Lederrey* (he/him) Engineering Manager Wikimedia Foundation <https://wikimediafoundation.org/>

1 1

Forthcoming maintenance to irc.wikimedia.org - Moving to ircstream
by Moritz Mühlenhoff 30 Sep '25

30 Sep '25

Hi all, we're moving irc.wikimedia.org to a new infrastructure [1]. This service is unrelated to the IRC network (Libera) we use for real time discussions. Instead irc.wikimedia.org is an IRC service for broadcasting recent changes events from public Wikimedia wikis to be used by various bots connected to per-wiki IRC channels. irc.wikimedia.org should not be used for any new bots (which should rather use Eventstreams[2]), but we still have various important bots relying on the legacy IRC-based infrastructure. The current setup is full of technical debt and ultimately based on a patched version of a very old release of ircd-ratbox with a relay service written in Python 2. We are replacing it with a modern standalone implementation in Python, which broadcasts IRC notifications in a format compatible to what is currently in use by the legacy setup: https://github.com/paravoid/ircstream Last week during the SRE Infrastructure Foundations hackathon the ircstream production setup was created. All our tests have been successful, so on Thursday October 10 at 08:00 UTC we'll switch the irc.wikimedia.org DNS name to the new setup. No changes are needed to any bots, but if you run into any issues after the switch, please notify us in the #wikimedia-sre-foundations IRC channel or leave a note at https://phabricator.wikimedia.org/T376014. Cheers, Luca, Simon and Moritz Footnotes: [1] https://wikitech.wikimedia.org/wiki/Irc.wikimedia.org [2] https://wikitech.wikimedia.org/wiki/Event_Platform/EventStreams_HTTP_Service

4 3

Announcing shared co-ownership of the nodejs service-utils library.
by Alexandros Kosiaris 30 Sep '25

30 Sep '25

Hi everyone, TL;DR SRE will be co-owning, together with Thomas Chin of Data Platform Engineering, the service-utils <https://www.mediawiki.org/wiki/Service-utils> Node.js utilities library, service-runner <https://www.mediawiki.org/wiki/Service-runner>'s spiritual successor and replacement. If you are thinking about starting a new Node.js service to be deployed in production, using service-utils is expected to greatly reduce friction, speed up development and allow you to focus on your business needs instead of how to satisfy SRE requirements for getting the service deployed. If you already own one or more services that is (are) service-runner powered, consider migrating to service-utils at your convenience. Background Service-runner <https://github.com/wikimedia/service-runner> is a library that provides generalized runtime facilities for Node.js services, including: - a standard worker cluster setup with restarts, - a generalized YAML config format with support for running multiple services in a single process, - runtime facilities for - logging - metrics reporting - rate limiting. Usage in Foundation produced code and micro services is thought to have increased the productivity of developer and SRE teams by abstracting and automating away, the important but unrelated to the actual goals of the developer teams, requirements mentioned above. Ongoing support from the owning team, which is no longer extant, the Services team, also played a pivotal role. Out of the 20 NodeJS apps (powering 25 services), 15 currently use it (those not using it are either pioneering service-utils already or are trying out other solutions). Unfortunately, it is also abandoned. Node.js developers have noticed and the Phabricator workboard <https://phabricator.wikimedia.org/project/view/1062/> makes this evident, with Task Titles like "service-runner has vulnerable and outdated dependencies", "service-runner depends on preq, a wrapper of request, which is deprecated". Some efforts have been made to find a replacement. Thomas Chin has been kind enough to create service-utils, a library designed to be compatible (if not a drop-in replacement in many cases) with service-runner. However, maintaining this library isn't Thomas' nor the Data Platform Engineering team's mission. This has, unsurprisingly, led to lower than wished for (by SRE at least) adoption. Next steps SRE will be, starting in Q2 2025-2026 - Becoming more familiar with the code base - Updating documentation as needed. - Helping with ongoing maintenance of the library - Providing help and guidance for migration from service-runner to service-utils - Going through the backlog of work tracked in the corresponding Phabricator work boards for the 2 projects and implement/resolve bug/decline/stall as deemed appropriate, always after discussions with relevant stakeholders. - Contributing the following features they are interested in: - Abstracting away talking to the service-mesh - Finish testing and rolling out support for Open Telemetry - Announcing the full deprecation of service-runner, archival of code repositories and removal from library repositories (i.e. npm) when all, in scope, code bases have been migrated over. FAQIs this a full drop-in replacement? No. It's close enough for most use cases. However, service-runner is a decade old code base. Some of the functionalities it provides either no longer make sense in 2025 (e.g. worker cluster setup in a Kubernetes environment is not needed), made assumptions about the Infrastructure that no longer apply (e.g. rate limiting) or rely on entirely abandoned and non-salvageable libraries (e.g. kad that implements rate limiting). Those are not and will not be supported in service-utils. When should my team migrate to/adopt this? If you start a new Node.Js service in the WMF, go for this from day 1. If you already run a service-runner powered service, at your earliest convenience. Who do I talk to if I want some functionality implemented before I adopt this? Faster path forward is probably to come to either #wikimedia-sre on IRC or #talk-to-sre in Slack. SRE Service operations will respond. Is this tracked in the annual plan? Yes, most work is already under KR WE6.2, aka Production Readiness <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2025-2026/…>. Some parts of the work described above will be ongoing and tracked under Annual Essential Work

1 0

Tech News 2025, week 40
by Uzoma Ozurumba 29 Sep '25

29 Sep '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/40> are available. *Weekly highlight* - A major software upgrade has been made to Phabricator <https://phabricator.wikimedia.org/>. The update introduces performance improvements, a refreshed search interface, enhancements to Maniphest task search, updates to user profile pages and project workboards, new Herald automation features, as well as general text input, mobile experience improvements and more. [1] <https://phabricator.wikimedia.org/phame/post/view/321/iterative_improvement…> *Updates for editors* - The Community Tech team will release the new Community Wishlist extension on October 1, that will improve the way wishes will be submitted. The new extension will allow users to add tags to their wishes to better categorise them, and (in a future iteration) to filter them by status, tags and focus areas. It will also be possible to support individual wishes again, as requested by the community in many instances. The old system will be retired. There will be a brief period of downtime while the extension is deployed and wishes are migrated to the new system. You can read more about this in the latest update <https://meta.wikimedia.org/wiki/Special:MyLanguage/Community_Wishlist/Updat…> or you can consult the current documentation on MediaWiki <https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Extension:CommunityR…> . - As announced on Diff blog <https://diff.wikimedia.org/2025/09/02/better-detecting-bots-and-replacing-o…>, the production trial of the hCaptcha <https://www.mediawiki.org/wiki/Special:MyLanguage/Product_Safety_and_Integr…> service for bot detection has begun. The trial is currently using hCaptcha to protect account creation on Chinese, Persian, Portuguese, Indonesian, Japanese, and Turkish Wikipedias, where it will replace our existing CAPTCHA <https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:ConfirmEdit#Fan…> (FancyCaptcha). The goal with the trial is to better block bots while also improving usability and accessibility for users who encounter CAPTCHA challenges. - The CampaignEvents <https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:CampaignEvents> extension has been deployed <https://meta.wikimedia.org/wiki/Special:MyLanguage/CampaignEvents/Deploymen…> to Wikimedia Commons. The extension makes it easier to organize and participate in collaborative activities, like edit-a-thons and WikiProjects, on the wikis. On Commons, anyone who is a registered user can use it as an event participant. To use it as an organizer, someone needs to have the event organizer right <https://commons.wikimedia.org/wiki/Special:MyLanguage/Commons:Event_organiz…> . - Sub-referencing <https://meta.wikimedia.org/wiki/Special:MyLanguage/WMDE_Technical_Wishes/Su…>, a new feature to re-use references with different details has been released to German Wikipedia. You can test the feature <https://meta.wikimedia.org/wiki/Special:MyLanguage/WMDE_Technical_Wishes/Su…> on testwiki or on betawiki <https://en.wikipedia.beta.wmcloud.org/wiki/Sub-referencing> as well. Please share your thoughts on using templates in sub-references <https://meta.wikimedia.org/wiki/Talk:WMDE_Technical_Wishes/Sub-referencing#…> or volunteer to become a pilot wiki <https://meta.wikimedia.org/wiki/Talk:WMDE_Technical_Wishes/Sub-referencing#…> . - On wikis using the Mentorship <https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Growth/Mentorship> system, communities can now opt experienced editors out of Mentorship through Special:CommunityConfiguration/Mentorship <https://meta.wikimedia.org/wiki/Special:CommunityConfiguration/Mentorship>. Within this setting, communities may define thresholds, based on edit count and account age, to decide when an editor is considered experienced enough to no longer receive Mentorship. [2] <https://phabricator.wikimedia.org/T403563> - The Editing Team and the Machine Learning Team are working on a new check for newcomers: Tone check <https://www.mediawiki.org/wiki/Special:MyLanguage/Edit_check/Tone_Check>. Using a prediction model, this check will encourage editors to improve the tone of their edits, using artificial intelligence. We invite volunteers to review the first version of the Tone language model for the following languages: Arabic, Czech, German, Hebrew, Indonesian, Dutch, Polish, Russian, Turkish, Chinese, Farsi, Italian, Norwegian, Romanian and Latvian. Users from these wikis interested in reviewing this model are invited to sign up at MediaWiki.org <https://www.mediawiki.org/wiki/Special:MyLanguage/Edit_check/Tone_Check/Mod…>. The deadline to sign up is on October 3, which will be the start date of the test. - The rollout of multiblocks <https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Manage_blocks> had the side effect that non-active block logs may have been shown on Special:Contributions and on blocked users' user and user_talk pages. This issue will be fully resolved in a few days. As part of the fix, messages prefixed with sp-contributions-blocked-notice <https://meta.wikimedia.org/w/index.php?title=Special:Allmessages&prefix=sp-…> will be removed and replaced with those prefixed with blocked-notice-logextract <https://meta.wikimedia.org/w/index.php?title=Special:Allmessages&prefix=blo…> in a few weeks. Please help translate the new messages and update any local overrides if needed. - There was a bug with links added using visual editor if they included characters such as [ ] | after the fragment identifier (#). They were not encoded properly creating an incorrect link. This has been fixed. [3] <https://phabricator.wikimedia.org/T404823> - One new wiki has been created: a Wikiquote in Malay <https://www.wikidata.org/wiki/Q9237> (q:ms: <https://en.wikiquote.org/wiki/ms:>) [4] <https://phabricator.wikimedia.org/T404698> - [image: Recurrent item] View all 21 community-submitted tasks that were resolved last week <https://meta.wikimedia.org/wiki/Special:MyLanguage/Tech/News/Recently_resol…>. For example, the User Info Card <https://www.mediawiki.org/wiki/Special:MyLanguage/Product_Safety_and_Integr…> now displays currently active global lock/blocks. [5] <https://phabricator.wikimedia.org/T401128> *Updates for technical contributors* - Later this week, editors using Lua modules will be able to use the mw.title.newBatch <https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:Scribunto/Lua_r…> function to look up the existence of up to 25 pages at once, in a way that only increases the expensive function <https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Parser_functions#E…> count once. - A new Unsupported Tools Working Group <https://meta.wikimedia.org/wiki/Special:MyLanguage/Product_and_Technology_A…> has been formed as part of ongoing efforts to collectively determine technical work priorities, similar to the Product & Technology Advisory Council <https://meta.wikimedia.org/wiki/Special:MyLanguage/Product_and_Technology_A…> (PTAC). The working group will help prioritize and review requests for support of unmaintained extensions, gadgets, bots, and tools. For the first cycle, the group will be prioritizing an unsupported Wikimedia Commons tool. - [image: Recurrent item] Detailed code updates later this week: MediaWiki <https://www.mediawiki.org/wiki/MediaWiki_1.45/wmf.21> *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/40> • 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…>.* -- Uzoma Ozurumba (She/her) Movement Communications Specialist (Product and Tech) meta.wikimedia.org/wiki/User:UOzurumba_(WMF)

1 0

/page/talk removal as part of the RESTBase Sunset effort
by Mateus Santos 29 Sep '25

29 Sep '25

Hello everyone, As part of the RESTBase Sunset effort, some endpoints are being phased out in favor of better, more stable alternatives or completely removed. The /page/talk <https://en.wikipedia.org/api/rest_v1/#/Talk%20pages> endpoint is now ready for deprecation. This endpoint is marked as experimental and its usage has been exclusively by the Android and iOS apps which teams signed off on the deprecation readiness <https://phabricator.wikimedia.org/T392491>. This endpoint has no alternatives. Next steps: because this is an experimental endpoint, we decided to apply the existing policy for REST endpoints <https://www.mediawiki.org/wiki/API_versioning#Experimental> and turn it off as soon as possible while still respecting Android and iOS old versions' deprecation timeline. Traffic to this endpoint can be blocked starting Today, Sep 29th 2025 (09/29/2025) and code will be removed after that. Details about the deprecation can be found in this phabricator task, T401895 <https://phabricator.wikimedia.org/T401895>. Don't hesitate in getting in touch in case you have any questions or concerns. Best regards, -- Mateus Santos Product Manager - 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 September 2025