+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 > > > > > > > > > > > > > > > > > > > > >
