Just to clarify: > However, I have some reservations about announcing a freeze in patch level releases as Jarek suggested.
The whole proposal is with "less freeze" - only when we have major changes. And yes I am all for "less" freezing - and only when we really need it as we know a lot of changes are added. > informs people of an upcoming release then include a paragraph for the translation but not call it a freeze? That's exactly what I proposed :) J. On Mon, Dec 8, 2025 at 1:47 PM Ephraim Anierobi <[email protected]> wrote: > +1 on the points. > > However, I have some reservations about announcing a freeze in patch level > releases as Jarek suggested. > And the reason is, patches happen every few weeks(2 or 3) unlike minor and > major releases. Won't that stop work > on the translations every month? Perhaps, we should make a more general > pre-release announcement email that > informs people of an upcoming release then include a paragraph for the > translation but not call it a freeze? > > - Ephraim > > On Mon, 8 Dec 2025 at 06:29, Amogh Desai <[email protected]> wrote: > > > 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 > > > > > > > > > > > > > > >
