Sounds reasonable! Added instructions and a reminder template for handling patches to the PR :)
Shahar On Sat, Dec 6, 2025 at 7:04 PM Jarek Potiuk <[email protected]> wrote: > +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 > > >
