Summer (heat) is (finally) ending in the part of the world where most of the Weblate team members reside. This is good news; there will be more hours each day to work on Weblate improvements without the decimating heat.
Today, let's look at the release 2026.9(.1).
There is a change in how we describe the handling of security reports from now on. With a growing usage of AI tools, we are receiving endless handful of reports. Even though that many times it is reporting a theory that is not really a feasible vector of attack (or is already fixed) we responsibly sort and fix all anyway. We want Weblate to remain the well-maintained, libre, transparent, secure, and best-possible platform. But with the growing amount of reports to all open projects, we cannot even receive CVE from GitHub reliably. A CVE received more than a month after everything is fixed and deployed is useless, and currently, nearly everybody in the open-source world has an endless backlog like this. And we prefer moving the development forward over unsustainable processes, writing non-essential content, and pursuing stats. Lip service has no value. Who wants to write reports about minuscule issues if nobody has time to read them? Isn't there a more user-benefiting and productive way to spend time on improving Weblate? So how do we continue?
We still will be publishing security advisories on GitHub for real high-severity issues. Those are rare for Weblate but can happen. Regular and low-severity security issues fixed as a part of each release will be listed in the dedicated section of each changelog. Nothing is hidden, only a simpler process that generates less content for you to read and digest.
What can you, an admin, do? Three simple steps:
— Always upgrade to Weblate's latest release. It is easy, swift, secure, and saves you possible work in case of possible (over a year's worth of) skipped updates. And it gives your localization team new options with each new feature! — Skim the Weblate changelogs while doing that, should you want to be informed in detail. — Subscribe to Weblate security alerts on GitHub if you wish to surely be notified about immediate threats. It's simple with a few clicks on Watch -> Custom -> Security alerts.
And what about new powers that Weblate 2026.9 and .1 give to your team?
Version control parameters were added to configure repository behavior per component, including force pushing, opting out of pull requests, and GitHub pull request auto-merge.
The rest of the .9 is mostly about bug fixing, code polishing, and cleanups all around the codebase. These continuous works are always preparing a base for future improvements, like the completely rewritten way of handling Celery in .9.1! This should remarkably boost server performance.
And as we were talking updates, there are two changes that can likely break something in specific setups, so — Webhook target matching no longer falls back to host/path suffix matching. Component repository URLs must match a repository URL from the webhook payload. If this is your case, here is the reading on how to solve it. — If you have a Docker deployment with no proxy addresses set, do it now. Set WEBLATE_TRUSTED_PROXY_ADDRESSES to preserve client IP addresses in nginx logs and Weblate when WEBLATE_IP_PROXY_HEADER=HTTP_X_FORWARDED_FOR is used; otherwise, the immediate TCP peer is used.
Are these last lines too technical jargon and unappealing for you? No worries, this is where we end this time. See you soon in less than a month with 2026.10, with some more enjoyable reading.
