Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2025-11): 356
Active Maniphest users (any activity) in (2025-11): 1124
Task authors in (2025-11): 609
Users who have closed tasks in (2025-11): 322
Projects which had at least one task moved from one column to another on
their workboard in (2025-11): 325
Tasks created in (2025-11): 2371
Tasks closed in (2025-11): 2225
Open and stalled tasks in total: 55874
* Only open tasks in total: 54793
* Only stalled tasks in total: 1081
Median age in days of open tasks by priority:
Unbreak now: 73
Needs Triage: 1164
High: 1499
Normal: 2314
Low: 2788
Lowest: 3667
(How long tasks have been open, not how long they have had that priority)
To see the names of the most active task authors:
* Go to https://wikimedia.biterg.io/
* Choose "Phabricator > Overview" from the top bar
* Adjust the time frame in the upper right corner to your needs
* See the author names in the "Submitters" panel
TODO: Numbers which refer to closed tasks might not be correct, as
described in https://phabricator.wikimedia.org/T1003 .
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on phab1004 at Mon 01 Dec 2025 12:00:38 AM UTC)
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/>
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
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>
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/>
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.
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/