+1 for reminders, and having that for patch releases too and having less freeze period.
On Mon 8 Dec 2025 at 21:28, Shahar Epstein <[email protected]> wrote: > +1 for that - in the patch level it's more of a reminder to keep up with > the changes. > Tracking actual maintenance is in releases of minor/major versions. > > > Shahar > > On Mon, Dec 8, 2025 at 7:08 PM Jarek Potiuk <[email protected]> wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
