Good idea. +1 for both points with Jarek's suggestions.
Thanks & Regards, Amogh Desai On Sat, Dec 6, 2025 at 11:04 PM Shahar Epstein <[email protected]> wrote: > 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 > > > > > >
