Implement simpler and faster freeze check for translations

[potiuk]

This is follow-up after #55119 - implements the translation freeze quite a bit simpler and faster:

• uses selective checks (fail fast)
• does not check the dates (we will set the flag to False when freeze time passes
• you can bypass the freeze with a label rather than having to commit exemption file

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[potiuk]

The failure is actually[ a demo how it will work:

1. First it failed (fast) with:

2. Then I am going to add a label and close/reopen

[potiuk]

3. Now it nicely works after I set the label:

[pierrejeambrun]

Nice improvement. (selective checks, flag + label)

[pierrejeambrun]

I would expect the workflows files to be updated accordingly, am I missing something? (I guess I am, can't remember how that ui_english_translation_changed props is invoked)

[potiuk]

Also just to illustrate my point: I rebased my change on top of main and fixed the remaining TODO. And you can already see how brittle the "_freeze_exemptions" is and how it blocks things from being fixed.

there were three things added to _freeze_exemptions:

"hitl": {
"requiredActionCount_one": "Required Action ({{count}})",
"requiredActionCount_other": "Required Actions ({{count}})",
"state": {
"noResponseReceived": "No Response Received"
}
},

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not). So that's already somewhat a discrepancy. And if you can look at my PR #55234 where I am closing the gap. The translation for "requiredActionCount" is added - because it was also added to en translation, but I do not have "noResponseReceived".

So as translator I basically ENOCARE whether I am workign towards a moving target or not - what I care about is that when I run the translation tool, I translate everything missing.

Also I think freeze_exemptions adds quite some complexity. We simply - for example - do not need the "hitl:" prefix - we referred in a few places with the the hitl: because we had to also add "_freeze_examptions" to "useTranslate" - but if we get rid of it, we can simplify those almost everywhere (except the menu).

BTW. I also found one missing "dags:" prefix and unused "common" in useTranslations.

[shahar1]

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not).

Adding these terms should have triggered the pre-commit and fail the PR that added them - it didn't happened since the specific PR that added these terms was merged without rebasing from main :)
After some rethinking - maybe the current freeze concept is indeed too strict and complex to handle. Maybe instead we could adjust the check_translations_completeness to compare the existing keys*, between the current state of main and when the freeze starts (=specified by commit SHA). That way we'll be able to have constant way of measuring completeness before release, while allowing making additions/modifications where needed.

* - We will have to ask avoiding removal of existing keys during this freeze, because then it could change the calculation...but I think it's the least worst.

WDYT?

[shahar1]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

[potiuk]

Small update to translation being done during freeze time.

After I merge this one (agreed with @shahar1) -> we are going to allow merging english new translations during freeze, but:

• A maintainer will have to expliclity set allow translation change label on the PR (without it - such PR will fail very early)
• When translation is merged, the one who merges it should ping in the #i18n slack channel that there is a new translation added during freeze

This should let us all know quickly when new translation is added, and give us more time, also fiddling with the _freeze_exemptions.json is removed - it's not been quite clear how to deal with it.

I tried to add every person from the translator's list to the #i18n but I failed to match some of the github names to the slack users - so please take a look at slack and add yourself to the #i18n channel if you are not there.

• ar: @shahar1@hussein-awala@ahmadtfarhan
• ca: @jscheffl@bugraoz93@ecodina
• de: @jscheffl@TJaniF@m1racoli
• es: @bbovenzi@aoelvp94
• fr: @pierrejeambrun@vincbeck
• he: @eladkal@shahar1@romsharon98@Dev-iL
• hi: @vatsrahul1001
• hu: @jscheffl@potiuk@majorosdonat
• ko: @jscheffl@potiuk@choo121600@kgw7401 @0ne-stone
• nl: @BasPH@DjVinnii
• pl: @potiuk@mobuchowski@kacpermuda
• tr: @bugraoz93@hasancatalgol
• zh-TW: @Lee-W@jason810496@RoyLee1224@guan404ming

[potiuk]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

Yeah - it was becaue some languages already had _freeze_exemptions.json - and (it was a bit inconsistent again) in some of those the translations were also in the "regular" files in some they were not (another reason why freeze_exemptions was generally a bit flawed).

I removed those and merged-in translations from those `_freeze_exempltions.json" that needed to be merged.

[potiuk]

Also @shahar1 -> as part of this PR i updated (and reformatted to fit 110 characters per line) README.md for i18n with referencese and description of:

• freeze time
• label
• the #18n channel in slack

Once we merge it, I will also drop a note on devlist.

[potiuk]

Known failure - being fixed in main,

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 8d7cc72 v3-0-test

This should apply the commit to the v3-0-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

[potiuk]

no backport

[potiuk]

This is follow-up after #55119 - implements the translation freeze quite a bit simpler and faster:

• uses selective checks (fail fast)
• does not check the dates (we will set the flag to False when freeze time passes
• you can bypass the freeze with a label rather than having to commit exemption file

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[potiuk]

The failure is actually[ a demo how it will work:

1. First it failed (fast) with:

2. Then I am going to add a label and close/reopen

[potiuk]

3. Now it nicely works after I set the label:

[pierrejeambrun]

Nice improvement. (selective checks, flag + label)

[pierrejeambrun]

I would expect the workflows files to be updated accordingly, am I missing something? (I guess I am, can't remember how that ui_english_translation_changed props is invoked)

[potiuk]

Also just to illustrate my point: I rebased my change on top of main and fixed the remaining TODO. And you can already see how brittle the "_freeze_exemptions" is and how it blocks things from being fixed.

there were three things added to _freeze_exemptions:

"hitl": {
"requiredActionCount_one": "Required Action ({{count}})",
"requiredActionCount_other": "Required Actions ({{count}})",
"state": {
"noResponseReceived": "No Response Received"
}
},

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not). So that's already somewhat a discrepancy. And if you can look at my PR #55234 where I am closing the gap. The translation for "requiredActionCount" is added - because it was also added to en translation, but I do not have "noResponseReceived".

So as translator I basically ENOCARE whether I am workign towards a moving target or not - what I care about is that when I run the translation tool, I translate everything missing.

Also I think freeze_exemptions adds quite some complexity. We simply - for example - do not need the "hitl:" prefix - we referred in a few places with the the hitl: because we had to also add "_freeze_examptions" to "useTranslate" - but if we get rid of it, we can simplify those almost everywhere (except the menu).

BTW. I also found one missing "dags:" prefix and unused "common" in useTranslations.

[shahar1]

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not).

Adding these terms should have triggered the pre-commit and fail the PR that added them - it didn't happened since the specific PR that added these terms was merged without rebasing from main :)
After some rethinking - maybe the current freeze concept is indeed too strict and complex to handle. Maybe instead we could adjust the check_translations_completeness to compare the existing keys*, between the current state of main and when the freeze starts (=specified by commit SHA). That way we'll be able to have constant way of measuring completeness before release, while allowing making additions/modifications where needed.

* - We will have to ask avoiding removal of existing keys during this freeze, because then it could change the calculation...but I think it's the least worst.

WDYT?

[shahar1]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

[potiuk]

Small update to translation being done during freeze time.

After I merge this one (agreed with @shahar1) -> we are going to allow merging english new translations during freeze, but:

• A maintainer will have to expliclity set allow translation change label on the PR (without it - such PR will fail very early)
• When translation is merged, the one who merges it should ping in the #i18n slack channel that there is a new translation added during freeze

This should let us all know quickly when new translation is added, and give us more time, also fiddling with the _freeze_exemptions.json is removed - it's not been quite clear how to deal with it.

I tried to add every person from the translator's list to the #i18n but I failed to match some of the github names to the slack users - so please take a look at slack and add yourself to the #i18n channel if you are not there.

• ar: @shahar1@hussein-awala@ahmadtfarhan
• ca: @jscheffl@bugraoz93@ecodina
• de: @jscheffl@TJaniF@m1racoli
• es: @bbovenzi@aoelvp94
• fr: @pierrejeambrun@vincbeck
• he: @eladkal@shahar1@romsharon98@Dev-iL
• hi: @vatsrahul1001
• hu: @jscheffl@potiuk@majorosdonat
• ko: @jscheffl@potiuk@choo121600@kgw7401 @0ne-stone
• nl: @BasPH@DjVinnii
• pl: @potiuk@mobuchowski@kacpermuda
• tr: @bugraoz93@hasancatalgol
• zh-TW: @Lee-W@jason810496@RoyLee1224@guan404ming

[potiuk]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

Yeah - it was becaue some languages already had _freeze_exemptions.json - and (it was a bit inconsistent again) in some of those the translations were also in the "regular" files in some they were not (another reason why freeze_exemptions was generally a bit flawed).

I removed those and merged-in translations from those `_freeze_exempltions.json" that needed to be merged.

[potiuk]

Also @shahar1 -> as part of this PR i updated (and reformatted to fit 110 characters per line) README.md for i18n with referencese and description of:

• freeze time
• label
• the #18n channel in slack

Once we merge it, I will also drop a note on devlist.

[potiuk]

Known failure - being fixed in main,

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 8d7cc72 v3-0-test

This should apply the commit to the v3-0-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

[potiuk]

no backport

[potiuk]

This is follow-up after #55119 - implements the translation freeze quite a bit simpler and faster:

• uses selective checks (fail fast)
• does not check the dates (we will set the flag to False when freeze time passes
• you can bypass the freeze with a label rather than having to commit exemption file

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[potiuk]

The failure is actually[ a demo how it will work:

1. First it failed (fast) with:

2. Then I am going to add a label and close/reopen

[potiuk]

3. Now it nicely works after I set the label:

[pierrejeambrun]

Nice improvement. (selective checks, flag + label)

[pierrejeambrun]

I would expect the workflows files to be updated accordingly, am I missing something? (I guess I am, can't remember how that ui_english_translation_changed props is invoked)

[potiuk]

Also just to illustrate my point: I rebased my change on top of main and fixed the remaining TODO. And you can already see how brittle the "_freeze_exemptions" is and how it blocks things from being fixed.

there were three things added to _freeze_exemptions:

"hitl": {
"requiredActionCount_one": "Required Action ({{count}})",
"requiredActionCount_other": "Required Actions ({{count}})",
"state": {
"noResponseReceived": "No Response Received"
}
},

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not). So that's already somewhat a discrepancy. And if you can look at my PR #55234 where I am closing the gap. The translation for "requiredActionCount" is added - because it was also added to en translation, but I do not have "noResponseReceived".

So as translator I basically ENOCARE whether I am workign towards a moving target or not - what I care about is that when I run the translation tool, I translate everything missing.

Also I think freeze_exemptions adds quite some complexity. We simply - for example - do not need the "hitl:" prefix - we referred in a few places with the the hitl: because we had to also add "_freeze_examptions" to "useTranslate" - but if we get rid of it, we can simplify those almost everywhere (except the menu).

BTW. I also found one missing "dags:" prefix and unused "common" in useTranslations.

[shahar1]

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not).

Adding these terms should have triggered the pre-commit and fail the PR that added them - it didn't happened since the specific PR that added these terms was merged without rebasing from main :)
After some rethinking - maybe the current freeze concept is indeed too strict and complex to handle. Maybe instead we could adjust the check_translations_completeness to compare the existing keys*, between the current state of main and when the freeze starts (=specified by commit SHA). That way we'll be able to have constant way of measuring completeness before release, while allowing making additions/modifications where needed.

* - We will have to ask avoiding removal of existing keys during this freeze, because then it could change the calculation...but I think it's the least worst.

WDYT?

[shahar1]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

[potiuk]

Small update to translation being done during freeze time.

After I merge this one (agreed with @shahar1) -> we are going to allow merging english new translations during freeze, but:

• A maintainer will have to expliclity set allow translation change label on the PR (without it - such PR will fail very early)
• When translation is merged, the one who merges it should ping in the #i18n slack channel that there is a new translation added during freeze

This should let us all know quickly when new translation is added, and give us more time, also fiddling with the _freeze_exemptions.json is removed - it's not been quite clear how to deal with it.

I tried to add every person from the translator's list to the #i18n but I failed to match some of the github names to the slack users - so please take a look at slack and add yourself to the #i18n channel if you are not there.

• ar: @shahar1@hussein-awala@ahmadtfarhan
• ca: @jscheffl@bugraoz93@ecodina
• de: @jscheffl@TJaniF@m1racoli
• es: @bbovenzi@aoelvp94
• fr: @pierrejeambrun@vincbeck
• he: @eladkal@shahar1@romsharon98@Dev-iL
• hi: @vatsrahul1001
• hu: @jscheffl@potiuk@majorosdonat
• ko: @jscheffl@potiuk@choo121600@kgw7401 @0ne-stone
• nl: @BasPH@DjVinnii
• pl: @potiuk@mobuchowski@kacpermuda
• tr: @bugraoz93@hasancatalgol
• zh-TW: @Lee-W@jason810496@RoyLee1224@guan404ming

[potiuk]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

Yeah - it was becaue some languages already had _freeze_exemptions.json - and (it was a bit inconsistent again) in some of those the translations were also in the "regular" files in some they were not (another reason why freeze_exemptions was generally a bit flawed).

I removed those and merged-in translations from those `_freeze_exempltions.json" that needed to be merged.

[potiuk]

Also @shahar1 -> as part of this PR i updated (and reformatted to fit 110 characters per line) README.md for i18n with referencese and description of:

• freeze time
• label
• the #18n channel in slack

Once we merge it, I will also drop a note on devlist.

[potiuk]

Known failure - being fixed in main,

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 8d7cc72 v3-0-test

This should apply the commit to the v3-0-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

[potiuk]

no backport

[potiuk]

This is follow-up after #55119 - implements the translation freeze quite a bit simpler and faster:

• uses selective checks (fail fast)
• does not check the dates (we will set the flag to False when freeze time passes
• you can bypass the freeze with a label rather than having to commit exemption file

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[potiuk]

The failure is actually[ a demo how it will work:

1. First it failed (fast) with:

2. Then I am going to add a label and close/reopen

[potiuk]

3. Now it nicely works after I set the label:

[pierrejeambrun]

Nice improvement. (selective checks, flag + label)

[pierrejeambrun]

I would expect the workflows files to be updated accordingly, am I missing something? (I guess I am, can't remember how that ui_english_translation_changed props is invoked)

[potiuk]

Also just to illustrate my point: I rebased my change on top of main and fixed the remaining TODO. And you can already see how brittle the "_freeze_exemptions" is and how it blocks things from being fixed.

there were three things added to _freeze_exemptions:

"hitl": {
"requiredActionCount_one": "Required Action ({{count}})",
"requiredActionCount_other": "Required Actions ({{count}})",
"state": {
"noResponseReceived": "No Response Received"
}
},

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not). So that's already somewhat a discrepancy. And if you can look at my PR #55234 where I am closing the gap. The translation for "requiredActionCount" is added - because it was also added to en translation, but I do not have "noResponseReceived".

So as translator I basically ENOCARE whether I am workign towards a moving target or not - what I care about is that when I run the translation tool, I translate everything missing.

Also I think freeze_exemptions adds quite some complexity. We simply - for example - do not need the "hitl:" prefix - we referred in a few places with the the hitl: because we had to also add "_freeze_examptions" to "useTranslate" - but if we get rid of it, we can simplify those almost everywhere (except the menu).

BTW. I also found one missing "dags:" prefix and unused "common" in useTranslations.

[shahar1]

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not).

Adding these terms should have triggered the pre-commit and fail the PR that added them - it didn't happened since the specific PR that added these terms was merged without rebasing from main :)
After some rethinking - maybe the current freeze concept is indeed too strict and complex to handle. Maybe instead we could adjust the check_translations_completeness to compare the existing keys*, between the current state of main and when the freeze starts (=specified by commit SHA). That way we'll be able to have constant way of measuring completeness before release, while allowing making additions/modifications where needed.

* - We will have to ask avoiding removal of existing keys during this freeze, because then it could change the calculation...but I think it's the least worst.

WDYT?

[shahar1]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

[potiuk]

Small update to translation being done during freeze time.

After I merge this one (agreed with @shahar1) -> we are going to allow merging english new translations during freeze, but:

• A maintainer will have to expliclity set allow translation change label on the PR (without it - such PR will fail very early)
• When translation is merged, the one who merges it should ping in the #i18n slack channel that there is a new translation added during freeze

This should let us all know quickly when new translation is added, and give us more time, also fiddling with the _freeze_exemptions.json is removed - it's not been quite clear how to deal with it.

I tried to add every person from the translator's list to the #i18n but I failed to match some of the github names to the slack users - so please take a look at slack and add yourself to the #i18n channel if you are not there.

• ar: @shahar1@hussein-awala@ahmadtfarhan
• ca: @jscheffl@bugraoz93@ecodina
• de: @jscheffl@TJaniF@m1racoli
• es: @bbovenzi@aoelvp94
• fr: @pierrejeambrun@vincbeck
• he: @eladkal@shahar1@romsharon98@Dev-iL
• hi: @vatsrahul1001
• hu: @jscheffl@potiuk@majorosdonat
• ko: @jscheffl@potiuk@choo121600@kgw7401 @0ne-stone
• nl: @BasPH@DjVinnii
• pl: @potiuk@mobuchowski@kacpermuda
• tr: @bugraoz93@hasancatalgol
• zh-TW: @Lee-W@jason810496@RoyLee1224@guan404ming

[potiuk]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

Yeah - it was becaue some languages already had _freeze_exemptions.json - and (it was a bit inconsistent again) in some of those the translations were also in the "regular" files in some they were not (another reason why freeze_exemptions was generally a bit flawed).

I removed those and merged-in translations from those `_freeze_exempltions.json" that needed to be merged.

[potiuk]

Also @shahar1 -> as part of this PR i updated (and reformatted to fit 110 characters per line) README.md for i18n with referencese and description of:

• freeze time
• label
• the #18n channel in slack

Once we merge it, I will also drop a note on devlist.

[potiuk]

Known failure - being fixed in main,

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 8d7cc72 v3-0-test

This should apply the commit to the v3-0-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

[potiuk]

no backport

[potiuk]

This is follow-up after #55119 - implements the translation freeze quite a bit simpler and faster:

• uses selective checks (fail fast)
• does not check the dates (we will set the flag to False when freeze time passes
• you can bypass the freeze with a label rather than having to commit exemption file

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[potiuk]

The failure is actually[ a demo how it will work:

1. First it failed (fast) with:

2. Then I am going to add a label and close/reopen

[potiuk]

3. Now it nicely works after I set the label:

[pierrejeambrun]

Nice improvement. (selective checks, flag + label)

[pierrejeambrun]

I would expect the workflows files to be updated accordingly, am I missing something? (I guess I am, can't remember how that ui_english_translation_changed props is invoked)

[potiuk]

Also just to illustrate my point: I rebased my change on top of main and fixed the remaining TODO. And you can already see how brittle the "_freeze_exemptions" is and how it blocks things from being fixed.

there were three things added to _freeze_exemptions:

"hitl": {
"requiredActionCount_one": "Required Action ({{count}})",
"requiredActionCount_other": "Required Actions ({{count}})",
"state": {
"noResponseReceived": "No Response Received"
}
},

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not). So that's already somewhat a discrepancy. And if you can look at my PR #55234 where I am closing the gap. The translation for "requiredActionCount" is added - because it was also added to en translation, but I do not have "noResponseReceived".

So as translator I basically ENOCARE whether I am workign towards a moving target or not - what I care about is that when I run the translation tool, I translate everything missing.

Also I think freeze_exemptions adds quite some complexity. We simply - for example - do not need the "hitl:" prefix - we referred in a few places with the the hitl: because we had to also add "_freeze_examptions" to "useTranslate" - but if we get rid of it, we can simplify those almost everywhere (except the menu).

BTW. I also found one missing "dags:" prefix and unused "common" in useTranslations.

[shahar1]

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not).

Adding these terms should have triggered the pre-commit and fail the PR that added them - it didn't happened since the specific PR that added these terms was merged without rebasing from main :)
After some rethinking - maybe the current freeze concept is indeed too strict and complex to handle. Maybe instead we could adjust the check_translations_completeness to compare the existing keys*, between the current state of main and when the freeze starts (=specified by commit SHA). That way we'll be able to have constant way of measuring completeness before release, while allowing making additions/modifications where needed.

* - We will have to ask avoiding removal of existing keys during this freeze, because then it could change the calculation...but I think it's the least worst.

WDYT?

[shahar1]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

[potiuk]

Small update to translation being done during freeze time.

After I merge this one (agreed with @shahar1) -> we are going to allow merging english new translations during freeze, but:

• A maintainer will have to expliclity set allow translation change label on the PR (without it - such PR will fail very early)
• When translation is merged, the one who merges it should ping in the #i18n slack channel that there is a new translation added during freeze

This should let us all know quickly when new translation is added, and give us more time, also fiddling with the _freeze_exemptions.json is removed - it's not been quite clear how to deal with it.

I tried to add every person from the translator's list to the #i18n but I failed to match some of the github names to the slack users - so please take a look at slack and add yourself to the #i18n channel if you are not there.

• ar: @shahar1@hussein-awala@ahmadtfarhan
• ca: @jscheffl@bugraoz93@ecodina
• de: @jscheffl@TJaniF@m1racoli
• es: @bbovenzi@aoelvp94
• fr: @pierrejeambrun@vincbeck
• he: @eladkal@shahar1@romsharon98@Dev-iL
• hi: @vatsrahul1001
• hu: @jscheffl@potiuk@majorosdonat
• ko: @jscheffl@potiuk@choo121600@kgw7401 @0ne-stone
• nl: @BasPH@DjVinnii
• pl: @potiuk@mobuchowski@kacpermuda
• tr: @bugraoz93@hasancatalgol
• zh-TW: @Lee-W@jason810496@RoyLee1224@guan404ming

[potiuk]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

Yeah - it was becaue some languages already had _freeze_exemptions.json - and (it was a bit inconsistent again) in some of those the translations were also in the "regular" files in some they were not (another reason why freeze_exemptions was generally a bit flawed).

I removed those and merged-in translations from those `_freeze_exempltions.json" that needed to be merged.

[potiuk]

Also @shahar1 -> as part of this PR i updated (and reformatted to fit 110 characters per line) README.md for i18n with referencese and description of:

• freeze time
• label
• the #18n channel in slack

Once we merge it, I will also drop a note on devlist.

[potiuk]

Known failure - being fixed in main,

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 8d7cc72 v3-0-test

This should apply the commit to the v3-0-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

[potiuk]

no backport

[potiuk]

This is follow-up after #55119 - implements the translation freeze quite a bit simpler and faster:

• uses selective checks (fail fast)
• does not check the dates (we will set the flag to False when freeze time passes
• you can bypass the freeze with a label rather than having to commit exemption file

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[potiuk]

The failure is actually[ a demo how it will work:

1. First it failed (fast) with:

2. Then I am going to add a label and close/reopen

[potiuk]

3. Now it nicely works after I set the label:

[pierrejeambrun]

Nice improvement. (selective checks, flag + label)

[pierrejeambrun]

I would expect the workflows files to be updated accordingly, am I missing something? (I guess I am, can't remember how that ui_english_translation_changed props is invoked)

[potiuk]

Also just to illustrate my point: I rebased my change on top of main and fixed the remaining TODO. And you can already see how brittle the "_freeze_exemptions" is and how it blocks things from being fixed.

there were three things added to _freeze_exemptions:

"hitl": {
"requiredActionCount_one": "Required Action ({{count}})",
"requiredActionCount_other": "Required Actions ({{count}})",
"state": {
"noResponseReceived": "No Response Received"
}
},

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not). So that's already somewhat a discrepancy. And if you can look at my PR #55234 where I am closing the gap. The translation for "requiredActionCount" is added - because it was also added to en translation, but I do not have "noResponseReceived".

So as translator I basically ENOCARE whether I am workign towards a moving target or not - what I care about is that when I run the translation tool, I translate everything missing.

Also I think freeze_exemptions adds quite some complexity. We simply - for example - do not need the "hitl:" prefix - we referred in a few places with the the hitl: because we had to also add "_freeze_examptions" to "useTranslate" - but if we get rid of it, we can simplify those almost everywhere (except the menu).

BTW. I also found one missing "dags:" prefix and unused "common" in useTranslations.

[shahar1]

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not).

Adding these terms should have triggered the pre-commit and fail the PR that added them - it didn't happened since the specific PR that added these terms was merged without rebasing from main :)
After some rethinking - maybe the current freeze concept is indeed too strict and complex to handle. Maybe instead we could adjust the check_translations_completeness to compare the existing keys*, between the current state of main and when the freeze starts (=specified by commit SHA). That way we'll be able to have constant way of measuring completeness before release, while allowing making additions/modifications where needed.

* - We will have to ask avoiding removal of existing keys during this freeze, because then it could change the calculation...but I think it's the least worst.

WDYT?

[shahar1]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

[potiuk]

Small update to translation being done during freeze time.

After I merge this one (agreed with @shahar1) -> we are going to allow merging english new translations during freeze, but:

• A maintainer will have to expliclity set allow translation change label on the PR (without it - such PR will fail very early)
• When translation is merged, the one who merges it should ping in the #i18n slack channel that there is a new translation added during freeze

This should let us all know quickly when new translation is added, and give us more time, also fiddling with the _freeze_exemptions.json is removed - it's not been quite clear how to deal with it.

I tried to add every person from the translator's list to the #i18n but I failed to match some of the github names to the slack users - so please take a look at slack and add yourself to the #i18n channel if you are not there.

• ar: @shahar1@hussein-awala@ahmadtfarhan
• ca: @jscheffl@bugraoz93@ecodina
• de: @jscheffl@TJaniF@m1racoli
• es: @bbovenzi@aoelvp94
• fr: @pierrejeambrun@vincbeck
• he: @eladkal@shahar1@romsharon98@Dev-iL
• hi: @vatsrahul1001
• hu: @jscheffl@potiuk@majorosdonat
• ko: @jscheffl@potiuk@choo121600@kgw7401 @0ne-stone
• nl: @BasPH@DjVinnii
• pl: @potiuk@mobuchowski@kacpermuda
• tr: @bugraoz93@hasancatalgol
• zh-TW: @Lee-W@jason810496@RoyLee1224@guan404ming

[potiuk]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

Yeah - it was becaue some languages already had _freeze_exemptions.json - and (it was a bit inconsistent again) in some of those the translations were also in the "regular" files in some they were not (another reason why freeze_exemptions was generally a bit flawed).

I removed those and merged-in translations from those `_freeze_exempltions.json" that needed to be merged.

[potiuk]

Also @shahar1 -> as part of this PR i updated (and reformatted to fit 110 characters per line) README.md for i18n with referencese and description of:

• freeze time
• label
• the #18n channel in slack

Once we merge it, I will also drop a note on devlist.

[potiuk]

Known failure - being fixed in main,

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 8d7cc72 v3-0-test

This should apply the commit to the v3-0-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

[potiuk]

no backport

[potiuk]

This is follow-up after #55119 - implements the translation freeze quite a bit simpler and faster:

• uses selective checks (fail fast)
• does not check the dates (we will set the flag to False when freeze time passes
• you can bypass the freeze with a label rather than having to commit exemption file

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[potiuk]

The failure is actually[ a demo how it will work:

1. First it failed (fast) with:

2. Then I am going to add a label and close/reopen

[potiuk]

3. Now it nicely works after I set the label:

[pierrejeambrun]

Nice improvement. (selective checks, flag + label)

[pierrejeambrun]

I would expect the workflows files to be updated accordingly, am I missing something? (I guess I am, can't remember how that ui_english_translation_changed props is invoked)

[potiuk]

Also just to illustrate my point: I rebased my change on top of main and fixed the remaining TODO. And you can already see how brittle the "_freeze_exemptions" is and how it blocks things from being fixed.

there were three things added to _freeze_exemptions:

"hitl": {
"requiredActionCount_one": "Required Action ({{count}})",
"requiredActionCount_other": "Required Actions ({{count}})",
"state": {
"noResponseReceived": "No Response Received"
}
},

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not). So that's already somewhat a discrepancy. And if you can look at my PR #55234 where I am closing the gap. The translation for "requiredActionCount" is added - because it was also added to en translation, but I do not have "noResponseReceived".

So as translator I basically ENOCARE whether I am workign towards a moving target or not - what I care about is that when I run the translation tool, I translate everything missing.

Also I think freeze_exemptions adds quite some complexity. We simply - for example - do not need the "hitl:" prefix - we referred in a few places with the the hitl: because we had to also add "_freeze_examptions" to "useTranslate" - but if we get rid of it, we can simplify those almost everywhere (except the menu).

BTW. I also found one missing "dags:" prefix and unused "common" in useTranslations.

[shahar1]

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not).

Adding these terms should have triggered the pre-commit and fail the PR that added them - it didn't happened since the specific PR that added these terms was merged without rebasing from main :)
After some rethinking - maybe the current freeze concept is indeed too strict and complex to handle. Maybe instead we could adjust the check_translations_completeness to compare the existing keys*, between the current state of main and when the freeze starts (=specified by commit SHA). That way we'll be able to have constant way of measuring completeness before release, while allowing making additions/modifications where needed.

* - We will have to ask avoiding removal of existing keys during this freeze, because then it could change the calculation...but I think it's the least worst.

WDYT?

[shahar1]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

[potiuk]

Small update to translation being done during freeze time.

After I merge this one (agreed with @shahar1) -> we are going to allow merging english new translations during freeze, but:

• A maintainer will have to expliclity set allow translation change label on the PR (without it - such PR will fail very early)
• When translation is merged, the one who merges it should ping in the #i18n slack channel that there is a new translation added during freeze

This should let us all know quickly when new translation is added, and give us more time, also fiddling with the _freeze_exemptions.json is removed - it's not been quite clear how to deal with it.

I tried to add every person from the translator's list to the #i18n but I failed to match some of the github names to the slack users - so please take a look at slack and add yourself to the #i18n channel if you are not there.

• ar: @shahar1@hussein-awala@ahmadtfarhan
• ca: @jscheffl@bugraoz93@ecodina
• de: @jscheffl@TJaniF@m1racoli
• es: @bbovenzi@aoelvp94
• fr: @pierrejeambrun@vincbeck
• he: @eladkal@shahar1@romsharon98@Dev-iL
• hi: @vatsrahul1001
• hu: @jscheffl@potiuk@majorosdonat
• ko: @jscheffl@potiuk@choo121600@kgw7401 @0ne-stone
• nl: @BasPH@DjVinnii
• pl: @potiuk@mobuchowski@kacpermuda
• tr: @bugraoz93@hasancatalgol
• zh-TW: @Lee-W@jason810496@RoyLee1224@guan404ming

[potiuk]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

Yeah - it was becaue some languages already had _freeze_exemptions.json - and (it was a bit inconsistent again) in some of those the translations were also in the "regular" files in some they were not (another reason why freeze_exemptions was generally a bit flawed).

I removed those and merged-in translations from those `_freeze_exempltions.json" that needed to be merged.

[potiuk]

Also @shahar1 -> as part of this PR i updated (and reformatted to fit 110 characters per line) README.md for i18n with referencese and description of:

• freeze time
• label
• the #18n channel in slack

Once we merge it, I will also drop a note on devlist.

[potiuk]

Known failure - being fixed in main,

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 8d7cc72 v3-0-test

This should apply the commit to the v3-0-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

[potiuk]

no backport

[potiuk]

This is follow-up after #55119 - implements the translation freeze quite a bit simpler and faster:

• uses selective checks (fail fast)
• does not check the dates (we will set the flag to False when freeze time passes
• you can bypass the freeze with a label rather than having to commit exemption file

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[potiuk]

The failure is actually[ a demo how it will work:

1. First it failed (fast) with:

2. Then I am going to add a label and close/reopen

[potiuk]

3. Now it nicely works after I set the label:

[pierrejeambrun]

Nice improvement. (selective checks, flag + label)

[pierrejeambrun]

I would expect the workflows files to be updated accordingly, am I missing something? (I guess I am, can't remember how that ui_english_translation_changed props is invoked)

[potiuk]

Also just to illustrate my point: I rebased my change on top of main and fixed the remaining TODO. And you can already see how brittle the "_freeze_exemptions" is and how it blocks things from being fixed.

there were three things added to _freeze_exemptions:

"hitl": {
"requiredActionCount_one": "Required Action ({{count}})",
"requiredActionCount_other": "Required Actions ({{count}})",
"state": {
"noResponseReceived": "No Response Received"
}
},

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not). So that's already somewhat a discrepancy. And if you can look at my PR #55234 where I am closing the gap. The translation for "requiredActionCount" is added - because it was also added to en translation, but I do not have "noResponseReceived".

So as translator I basically ENOCARE whether I am workign towards a moving target or not - what I care about is that when I run the translation tool, I translate everything missing.

Also I think freeze_exemptions adds quite some complexity. We simply - for example - do not need the "hitl:" prefix - we referred in a few places with the the hitl: because we had to also add "_freeze_examptions" to "useTranslate" - but if we get rid of it, we can simplify those almost everywhere (except the menu).

BTW. I also found one missing "dags:" prefix and unused "common" in useTranslations.

[shahar1]

But if you look closer, requiredActionCount_one , requiredActionCount_other - were also added to en/hitl.json (but noResponseReceived was not).

Adding these terms should have triggered the pre-commit and fail the PR that added them - it didn't happened since the specific PR that added these terms was merged without rebasing from main :)
After some rethinking - maybe the current freeze concept is indeed too strict and complex to handle. Maybe instead we could adjust the check_translations_completeness to compare the existing keys*, between the current state of main and when the freeze starts (=specified by commit SHA). That way we'll be able to have constant way of measuring completeness before release, while allowing making additions/modifications where needed.

* - We will have to ask avoiding removal of existing keys during this freeze, because then it could change the calculation...but I think it's the least worst.

WDYT?

[shahar1]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

[potiuk]

Small update to translation being done during freeze time.

After I merge this one (agreed with @shahar1) -> we are going to allow merging english new translations during freeze, but:

• A maintainer will have to expliclity set allow translation change label on the PR (without it - such PR will fail very early)
• When translation is merged, the one who merges it should ping in the #i18n slack channel that there is a new translation added during freeze

This should let us all know quickly when new translation is added, and give us more time, also fiddling with the _freeze_exemptions.json is removed - it's not been quite clear how to deal with it.

I tried to add every person from the translator's list to the #i18n but I failed to match some of the github names to the slack users - so please take a look at slack and add yourself to the #i18n channel if you are not there.

• ar: @shahar1@hussein-awala@ahmadtfarhan
• ca: @jscheffl@bugraoz93@ecodina
• de: @jscheffl@TJaniF@m1racoli
• es: @bbovenzi@aoelvp94
• fr: @pierrejeambrun@vincbeck
• he: @eladkal@shahar1@romsharon98@Dev-iL
• hi: @vatsrahul1001
• hu: @jscheffl@potiuk@majorosdonat
• ko: @jscheffl@potiuk@choo121600@kgw7401 @0ne-stone
• nl: @BasPH@DjVinnii
• pl: @potiuk@mobuchowski@kacpermuda
• tr: @bugraoz93@hasancatalgol
• zh-TW: @Lee-W@jason810496@RoyLee1224@guan404ming

[potiuk]

Following my last comment - I'm OK with giving up on the _freeze_exemptions concept :)
Thanks Jarek! (CI currently fails probably due to small issue)

Yeah - it was becaue some languages already had _freeze_exemptions.json - and (it was a bit inconsistent again) in some of those the translations were also in the "regular" files in some they were not (another reason why freeze_exemptions was generally a bit flawed).

I removed those and merged-in translations from those `_freeze_exempltions.json" that needed to be merged.

[potiuk]

Also @shahar1 -> as part of this PR i updated (and reformatted to fit 110 characters per line) README.md for i18n with referencese and description of:

• freeze time
• label
• the #18n channel in slack

Once we merge it, I will also drop a note on devlist.

[potiuk]

Known failure - being fixed in main,

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 8d7cc72 v3-0-test

This should apply the commit to the v3-0-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

[potiuk]

no backport