+1 on both. I think freeze is difficult to coordinate and a bit disruptive. and I think it is relatively easy to add missing phrases quickly. And yes. We should definitely have reminders before release - and having a template to follow and [ANNOUNCE] is a good idea to trigger adding missing phrases.
Also maybe one proposal: we seem to have **some** not huge, but quite regular changes in patchlevel releases - and I don't think it's something temporary, it will likely happen all the time in the future - maybe we should have a light version of such reminder also before patchlevel released - to add missing phrases in v3-X-test branch. Those changes are not often cherry-pickable, but applying the few (usually) small phrases should not be a big issue. J. J. On Sat, Dec 6, 2025 at 5:48 PM Shahar Epstein <[email protected]> wrote: > Hey everyone, > > While making updates to the translations I’m responsible for, I realized > that although the translation freeze mechanism was very effective just > before the initial release of the i18n feature (with all 18+ languages > included), it does not seem necessary for every minor or major release and > could become a potential bottleneck for both the release managers as well > as contributors. > In addition, with AI-based tooling, completing missing terms has become an > easier task for translation owners to bring their locales above the > required threshold in no-time - so for completing only dozens of terms for > the most time, there's no good justification for the freeze to be applied. > > For that reason, I created PR #59136 > <https://github.com/apache/airflow/pull/59136/files>, which introduces the > following changes in the policy: > 1. Instead of requiring a freeze for *every *major or minor release, a > freeze will be applied only when the median* coverage across all languages > is below the 90% threshold, or when deemed necessary by the release manager > (e.g., when a critical UI feature introduces many new terms). The idea is > to use the freeze when *many *changes need to be applied across *many > *translations > (well above 100 terms), and not when specific translation(s) are simply > unmaintained for too long. > 2. A simple completeness check *should *be performed in every minor and > major release, after which a thread should be posted on the dev list asking > code owners to ensure completion (90%+) by the RC release (a mail template > is included in the PR). Non-completed translations after the due date > should be tracked for the subsequent release. > > * - median and not average to reduce sensitivity for outliers. > > I'll be happy to hear your opinions regarding it before making it to a lazy > consensus in the upcoming days :) > > > Shahar >
