Implement default language (English) freeze pre-commit

[shahar1]

Following the recent dev call, this PR introduces a pre-commit to prevent changes in the default language during freeze time. The current freeze will be between Sep. 1 to Sep 9 (inc.); all times are arbitrarily measured in UTC AoE time.
This pre-commit should be reused in later freezes simply by changing the dates (I'll add it to the i18n policy).

---

^ 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.

[Lee-W]

It would be great if we can get #55041 merged before this

[Lee-W]

did a quick fix for the missing import

[Lee-W]

After a second thought, should we set time zone as AoE instead?

[shahar1]

did a quick fix for the missing import

Thanks! I also realized that it didn't actually check if there was a difference in the files during these dates, so I added a "git diff" call :)

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

[Lee-W]

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

Works for me :)

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

I learned this from the Python community, probably EuroPython. I find it very inclusive and it makes everyone's day easier, especially in a cross-timezone community. That's why I'm kinda a promoter of this idea haha

[potiuk]

After a second thought, should we set time zone as AoE instead?

Nice :)

Comment: do we need the dates here at ALL ?

I think it will be enough if we just enable "freeze" in this commit and then "disable" it by a second commit after we unfroze it.

While the dates are nice from informational point of view (and we should leave them in in the messages, this one gives us extra flexibility - because we can unfreeze it deliberately rather than automatically

[potiuk]

Another comment. Maybe a better way would be to add the mechanism to fail and unfreeze in selective checks. We already done that in the past and it has a few nice properties:

1. It can fail FAST -> if selective checks check fails, no other job runs, the PR fails almost immediately
2. we already have "changed files" built in and we can use it from there
3. we can use "labels" to make exemptions ("allow to modify translations" for example) rather than commit "exemptions file". How it works (we do it already) - we need to set a specified label on the PR to skip the check for modified translations. So rather than finding out how to modify exemptions files,a committer has to deliberately set "allow to modify translations") to let the PR pass the selective checks.
4. you can unit test is with test_selective_checks.py

It's also very easy to test:

breeze ci selective-checks --commit-ref <HASH> --pr-labels "label"`

We do it already a very similar way if suspended providers are affected:

https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L1376

Some pointers how we can do it:

• add a new property in SelectiveChecks "english_translation_affected" (it will be automatically converted into output in GitHubActions
• make it return true if "en" translations are in "changed files" https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L144
• in the property method check a constant (True) in this commit "FAIL_IF_EN_TRANSLATION_MODIFIED" (for now - we can set to False when we want to disable the check) and sys.exit(1) with the right error message if en translation is in changed files unless "allow to modify translations" label is set (similarly as we do in https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L884

[Lee-W]

sounds like a good idea 🤔

[shahar1]

Thanks for the feedback, Jarek! As we discussed on Slack, converting it into a selective check would be a follow up :)

[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 4579a38 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]

The simpler freeze here #55154

[shahar1]

Following the recent dev call, this PR introduces a pre-commit to prevent changes in the default language during freeze time. The current freeze will be between Sep. 1 to Sep 9 (inc.); all times are arbitrarily measured in UTC AoE time.
This pre-commit should be reused in later freezes simply by changing the dates (I'll add it to the i18n policy).

---

^ 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.

[Lee-W]

It would be great if we can get #55041 merged before this

[Lee-W]

did a quick fix for the missing import

[Lee-W]

After a second thought, should we set time zone as AoE instead?

[shahar1]

did a quick fix for the missing import

Thanks! I also realized that it didn't actually check if there was a difference in the files during these dates, so I added a "git diff" call :)

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

[Lee-W]

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

Works for me :)

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

I learned this from the Python community, probably EuroPython. I find it very inclusive and it makes everyone's day easier, especially in a cross-timezone community. That's why I'm kinda a promoter of this idea haha

[potiuk]

After a second thought, should we set time zone as AoE instead?

Nice :)

Comment: do we need the dates here at ALL ?

I think it will be enough if we just enable "freeze" in this commit and then "disable" it by a second commit after we unfroze it.

While the dates are nice from informational point of view (and we should leave them in in the messages, this one gives us extra flexibility - because we can unfreeze it deliberately rather than automatically

[potiuk]

Another comment. Maybe a better way would be to add the mechanism to fail and unfreeze in selective checks. We already done that in the past and it has a few nice properties:

1. It can fail FAST -> if selective checks check fails, no other job runs, the PR fails almost immediately
2. we already have "changed files" built in and we can use it from there
3. we can use "labels" to make exemptions ("allow to modify translations" for example) rather than commit "exemptions file". How it works (we do it already) - we need to set a specified label on the PR to skip the check for modified translations. So rather than finding out how to modify exemptions files,a committer has to deliberately set "allow to modify translations") to let the PR pass the selective checks.
4. you can unit test is with test_selective_checks.py

It's also very easy to test:

breeze ci selective-checks --commit-ref <HASH> --pr-labels "label"`

We do it already a very similar way if suspended providers are affected:

https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L1376

Some pointers how we can do it:

• add a new property in SelectiveChecks "english_translation_affected" (it will be automatically converted into output in GitHubActions
• make it return true if "en" translations are in "changed files" https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L144
• in the property method check a constant (True) in this commit "FAIL_IF_EN_TRANSLATION_MODIFIED" (for now - we can set to False when we want to disable the check) and sys.exit(1) with the right error message if en translation is in changed files unless "allow to modify translations" label is set (similarly as we do in https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L884

[Lee-W]

sounds like a good idea 🤔

[shahar1]

Thanks for the feedback, Jarek! As we discussed on Slack, converting it into a selective check would be a follow up :)

[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 4579a38 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]

The simpler freeze here #55154

[shahar1]

Following the recent dev call, this PR introduces a pre-commit to prevent changes in the default language during freeze time. The current freeze will be between Sep. 1 to Sep 9 (inc.); all times are arbitrarily measured in UTC AoE time.
This pre-commit should be reused in later freezes simply by changing the dates (I'll add it to the i18n policy).

---

^ 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.

[Lee-W]

It would be great if we can get #55041 merged before this

[Lee-W]

did a quick fix for the missing import

[Lee-W]

After a second thought, should we set time zone as AoE instead?

[shahar1]

did a quick fix for the missing import

Thanks! I also realized that it didn't actually check if there was a difference in the files during these dates, so I added a "git diff" call :)

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

[Lee-W]

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

Works for me :)

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

I learned this from the Python community, probably EuroPython. I find it very inclusive and it makes everyone's day easier, especially in a cross-timezone community. That's why I'm kinda a promoter of this idea haha

[potiuk]

After a second thought, should we set time zone as AoE instead?

Nice :)

Comment: do we need the dates here at ALL ?

I think it will be enough if we just enable "freeze" in this commit and then "disable" it by a second commit after we unfroze it.

While the dates are nice from informational point of view (and we should leave them in in the messages, this one gives us extra flexibility - because we can unfreeze it deliberately rather than automatically

[potiuk]

Another comment. Maybe a better way would be to add the mechanism to fail and unfreeze in selective checks. We already done that in the past and it has a few nice properties:

1. It can fail FAST -> if selective checks check fails, no other job runs, the PR fails almost immediately
2. we already have "changed files" built in and we can use it from there
3. we can use "labels" to make exemptions ("allow to modify translations" for example) rather than commit "exemptions file". How it works (we do it already) - we need to set a specified label on the PR to skip the check for modified translations. So rather than finding out how to modify exemptions files,a committer has to deliberately set "allow to modify translations") to let the PR pass the selective checks.
4. you can unit test is with test_selective_checks.py

It's also very easy to test:

breeze ci selective-checks --commit-ref <HASH> --pr-labels "label"`

We do it already a very similar way if suspended providers are affected:

https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L1376

Some pointers how we can do it:

• add a new property in SelectiveChecks "english_translation_affected" (it will be automatically converted into output in GitHubActions
• make it return true if "en" translations are in "changed files" https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L144
• in the property method check a constant (True) in this commit "FAIL_IF_EN_TRANSLATION_MODIFIED" (for now - we can set to False when we want to disable the check) and sys.exit(1) with the right error message if en translation is in changed files unless "allow to modify translations" label is set (similarly as we do in https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L884

[Lee-W]

sounds like a good idea 🤔

[shahar1]

Thanks for the feedback, Jarek! As we discussed on Slack, converting it into a selective check would be a follow up :)

[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 4579a38 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]

The simpler freeze here #55154

[shahar1]

Following the recent dev call, this PR introduces a pre-commit to prevent changes in the default language during freeze time. The current freeze will be between Sep. 1 to Sep 9 (inc.); all times are arbitrarily measured in UTC AoE time.
This pre-commit should be reused in later freezes simply by changing the dates (I'll add it to the i18n policy).

---

^ 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.

[Lee-W]

It would be great if we can get #55041 merged before this

[Lee-W]

did a quick fix for the missing import

[Lee-W]

After a second thought, should we set time zone as AoE instead?

[shahar1]

did a quick fix for the missing import

Thanks! I also realized that it didn't actually check if there was a difference in the files during these dates, so I added a "git diff" call :)

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

[Lee-W]

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

Works for me :)

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

I learned this from the Python community, probably EuroPython. I find it very inclusive and it makes everyone's day easier, especially in a cross-timezone community. That's why I'm kinda a promoter of this idea haha

[potiuk]

After a second thought, should we set time zone as AoE instead?

Nice :)

Comment: do we need the dates here at ALL ?

I think it will be enough if we just enable "freeze" in this commit and then "disable" it by a second commit after we unfroze it.

While the dates are nice from informational point of view (and we should leave them in in the messages, this one gives us extra flexibility - because we can unfreeze it deliberately rather than automatically

[potiuk]

Another comment. Maybe a better way would be to add the mechanism to fail and unfreeze in selective checks. We already done that in the past and it has a few nice properties:

1. It can fail FAST -> if selective checks check fails, no other job runs, the PR fails almost immediately
2. we already have "changed files" built in and we can use it from there
3. we can use "labels" to make exemptions ("allow to modify translations" for example) rather than commit "exemptions file". How it works (we do it already) - we need to set a specified label on the PR to skip the check for modified translations. So rather than finding out how to modify exemptions files,a committer has to deliberately set "allow to modify translations") to let the PR pass the selective checks.
4. you can unit test is with test_selective_checks.py

It's also very easy to test:

breeze ci selective-checks --commit-ref <HASH> --pr-labels "label"`

We do it already a very similar way if suspended providers are affected:

https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L1376

Some pointers how we can do it:

• add a new property in SelectiveChecks "english_translation_affected" (it will be automatically converted into output in GitHubActions
• make it return true if "en" translations are in "changed files" https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L144
• in the property method check a constant (True) in this commit "FAIL_IF_EN_TRANSLATION_MODIFIED" (for now - we can set to False when we want to disable the check) and sys.exit(1) with the right error message if en translation is in changed files unless "allow to modify translations" label is set (similarly as we do in https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L884

[Lee-W]

sounds like a good idea 🤔

[shahar1]

Thanks for the feedback, Jarek! As we discussed on Slack, converting it into a selective check would be a follow up :)

[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 4579a38 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]

The simpler freeze here #55154

[shahar1]

Following the recent dev call, this PR introduces a pre-commit to prevent changes in the default language during freeze time. The current freeze will be between Sep. 1 to Sep 9 (inc.); all times are arbitrarily measured in UTC AoE time.
This pre-commit should be reused in later freezes simply by changing the dates (I'll add it to the i18n policy).

---

^ 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.

[Lee-W]

It would be great if we can get #55041 merged before this

[Lee-W]

did a quick fix for the missing import

[Lee-W]

After a second thought, should we set time zone as AoE instead?

[shahar1]

did a quick fix for the missing import

Thanks! I also realized that it didn't actually check if there was a difference in the files during these dates, so I added a "git diff" call :)

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

[Lee-W]

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

Works for me :)

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

I learned this from the Python community, probably EuroPython. I find it very inclusive and it makes everyone's day easier, especially in a cross-timezone community. That's why I'm kinda a promoter of this idea haha

[potiuk]

After a second thought, should we set time zone as AoE instead?

Nice :)

Comment: do we need the dates here at ALL ?

I think it will be enough if we just enable "freeze" in this commit and then "disable" it by a second commit after we unfroze it.

While the dates are nice from informational point of view (and we should leave them in in the messages, this one gives us extra flexibility - because we can unfreeze it deliberately rather than automatically

[potiuk]

Another comment. Maybe a better way would be to add the mechanism to fail and unfreeze in selective checks. We already done that in the past and it has a few nice properties:

1. It can fail FAST -> if selective checks check fails, no other job runs, the PR fails almost immediately
2. we already have "changed files" built in and we can use it from there
3. we can use "labels" to make exemptions ("allow to modify translations" for example) rather than commit "exemptions file". How it works (we do it already) - we need to set a specified label on the PR to skip the check for modified translations. So rather than finding out how to modify exemptions files,a committer has to deliberately set "allow to modify translations") to let the PR pass the selective checks.
4. you can unit test is with test_selective_checks.py

It's also very easy to test:

breeze ci selective-checks --commit-ref <HASH> --pr-labels "label"`

We do it already a very similar way if suspended providers are affected:

https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L1376

Some pointers how we can do it:

• add a new property in SelectiveChecks "english_translation_affected" (it will be automatically converted into output in GitHubActions
• make it return true if "en" translations are in "changed files" https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L144
• in the property method check a constant (True) in this commit "FAIL_IF_EN_TRANSLATION_MODIFIED" (for now - we can set to False when we want to disable the check) and sys.exit(1) with the right error message if en translation is in changed files unless "allow to modify translations" label is set (similarly as we do in https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L884

[Lee-W]

sounds like a good idea 🤔

[shahar1]

Thanks for the feedback, Jarek! As we discussed on Slack, converting it into a selective check would be a follow up :)

[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 4579a38 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]

The simpler freeze here #55154

[shahar1]

Following the recent dev call, this PR introduces a pre-commit to prevent changes in the default language during freeze time. The current freeze will be between Sep. 1 to Sep 9 (inc.); all times are arbitrarily measured in UTC AoE time.
This pre-commit should be reused in later freezes simply by changing the dates (I'll add it to the i18n policy).

---

^ 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.

[Lee-W]

It would be great if we can get #55041 merged before this

[Lee-W]

did a quick fix for the missing import

[Lee-W]

After a second thought, should we set time zone as AoE instead?

[shahar1]

did a quick fix for the missing import

Thanks! I also realized that it didn't actually check if there was a difference in the files during these dates, so I added a "git diff" call :)

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

[Lee-W]

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

Works for me :)

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

I learned this from the Python community, probably EuroPython. I find it very inclusive and it makes everyone's day easier, especially in a cross-timezone community. That's why I'm kinda a promoter of this idea haha

[potiuk]

After a second thought, should we set time zone as AoE instead?

Nice :)

Comment: do we need the dates here at ALL ?

I think it will be enough if we just enable "freeze" in this commit and then "disable" it by a second commit after we unfroze it.

While the dates are nice from informational point of view (and we should leave them in in the messages, this one gives us extra flexibility - because we can unfreeze it deliberately rather than automatically

[potiuk]

Another comment. Maybe a better way would be to add the mechanism to fail and unfreeze in selective checks. We already done that in the past and it has a few nice properties:

1. It can fail FAST -> if selective checks check fails, no other job runs, the PR fails almost immediately
2. we already have "changed files" built in and we can use it from there
3. we can use "labels" to make exemptions ("allow to modify translations" for example) rather than commit "exemptions file". How it works (we do it already) - we need to set a specified label on the PR to skip the check for modified translations. So rather than finding out how to modify exemptions files,a committer has to deliberately set "allow to modify translations") to let the PR pass the selective checks.
4. you can unit test is with test_selective_checks.py

It's also very easy to test:

breeze ci selective-checks --commit-ref <HASH> --pr-labels "label"`

We do it already a very similar way if suspended providers are affected:

https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L1376

Some pointers how we can do it:

• add a new property in SelectiveChecks "english_translation_affected" (it will be automatically converted into output in GitHubActions
• make it return true if "en" translations are in "changed files" https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L144
• in the property method check a constant (True) in this commit "FAIL_IF_EN_TRANSLATION_MODIFIED" (for now - we can set to False when we want to disable the check) and sys.exit(1) with the right error message if en translation is in changed files unless "allow to modify translations" label is set (similarly as we do in https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L884

[Lee-W]

sounds like a good idea 🤔

[shahar1]

Thanks for the feedback, Jarek! As we discussed on Slack, converting it into a selective check would be a follow up :)

[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 4579a38 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]

The simpler freeze here #55154

[shahar1]

Following the recent dev call, this PR introduces a pre-commit to prevent changes in the default language during freeze time. The current freeze will be between Sep. 1 to Sep 9 (inc.); all times are arbitrarily measured in UTC AoE time.
This pre-commit should be reused in later freezes simply by changing the dates (I'll add it to the i18n policy).

---

^ 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.

[Lee-W]

It would be great if we can get #55041 merged before this

[Lee-W]

did a quick fix for the missing import

[Lee-W]

After a second thought, should we set time zone as AoE instead?

[shahar1]

did a quick fix for the missing import

Thanks! I also realized that it didn't actually check if there was a difference in the files during these dates, so I added a "git diff" call :)

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

[Lee-W]

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

Works for me :)

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

I learned this from the Python community, probably EuroPython. I find it very inclusive and it makes everyone's day easier, especially in a cross-timezone community. That's why I'm kinda a promoter of this idea haha

[potiuk]

After a second thought, should we set time zone as AoE instead?

Nice :)

Comment: do we need the dates here at ALL ?

I think it will be enough if we just enable "freeze" in this commit and then "disable" it by a second commit after we unfroze it.

While the dates are nice from informational point of view (and we should leave them in in the messages, this one gives us extra flexibility - because we can unfreeze it deliberately rather than automatically

[potiuk]

Another comment. Maybe a better way would be to add the mechanism to fail and unfreeze in selective checks. We already done that in the past and it has a few nice properties:

1. It can fail FAST -> if selective checks check fails, no other job runs, the PR fails almost immediately
2. we already have "changed files" built in and we can use it from there
3. we can use "labels" to make exemptions ("allow to modify translations" for example) rather than commit "exemptions file". How it works (we do it already) - we need to set a specified label on the PR to skip the check for modified translations. So rather than finding out how to modify exemptions files,a committer has to deliberately set "allow to modify translations") to let the PR pass the selective checks.
4. you can unit test is with test_selective_checks.py

It's also very easy to test:

breeze ci selective-checks --commit-ref <HASH> --pr-labels "label"`

We do it already a very similar way if suspended providers are affected:

https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L1376

Some pointers how we can do it:

• add a new property in SelectiveChecks "english_translation_affected" (it will be automatically converted into output in GitHubActions
• make it return true if "en" translations are in "changed files" https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L144
• in the property method check a constant (True) in this commit "FAIL_IF_EN_TRANSLATION_MODIFIED" (for now - we can set to False when we want to disable the check) and sys.exit(1) with the right error message if en translation is in changed files unless "allow to modify translations" label is set (similarly as we do in https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L884

[Lee-W]

sounds like a good idea 🤔

[shahar1]

Thanks for the feedback, Jarek! As we discussed on Slack, converting it into a selective check would be a follow up :)

[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 4579a38 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]

The simpler freeze here #55154

[shahar1]

Following the recent dev call, this PR introduces a pre-commit to prevent changes in the default language during freeze time. The current freeze will be between Sep. 1 to Sep 9 (inc.); all times are arbitrarily measured in UTC AoE time.
This pre-commit should be reused in later freezes simply by changing the dates (I'll add it to the i18n policy).

---

^ 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.

[Lee-W]

It would be great if we can get #55041 merged before this

[Lee-W]

did a quick fix for the missing import

[Lee-W]

After a second thought, should we set time zone as AoE instead?

[shahar1]

did a quick fix for the missing import

Thanks! I also realized that it didn't actually check if there was a difference in the files during these dates, so I added a "git diff" call :)

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

[Lee-W]

It would be great if we can get #55041 merged before this

The idea of the freeze is to align all translations against a constant source, so translation owners would be able to complete the gaps without "chasing" after the new changes every day until the release. To avoid blocking new features during this time, we could create an "exemption list" in a separate JSON file with the file names as keys. The translation owners won't be required to translate changes from this file and it will also be excluded from the completeness calculation. By the end of the freeze - we should relocate the terms from this file to their appropriate place. The trade-off for this flexibility is that terms might be missing from translations in the upcoming release, and we create a small debt to handle the list afterwards (we could relatively easily automate that).

@Lee-W@kaxil@potiuk@jscheffl@bbovenzi What do you all think?

Works for me :)

After a second thought, should we set time zone as AoE instead?

I wasn't aware that this term exists :D I'm ok with that, I assume that few hours to here and there won't make a significant difference.

I learned this from the Python community, probably EuroPython. I find it very inclusive and it makes everyone's day easier, especially in a cross-timezone community. That's why I'm kinda a promoter of this idea haha

[potiuk]

After a second thought, should we set time zone as AoE instead?

Nice :)

Comment: do we need the dates here at ALL ?

I think it will be enough if we just enable "freeze" in this commit and then "disable" it by a second commit after we unfroze it.

While the dates are nice from informational point of view (and we should leave them in in the messages, this one gives us extra flexibility - because we can unfreeze it deliberately rather than automatically

[potiuk]

Another comment. Maybe a better way would be to add the mechanism to fail and unfreeze in selective checks. We already done that in the past and it has a few nice properties:

1. It can fail FAST -> if selective checks check fails, no other job runs, the PR fails almost immediately
2. we already have "changed files" built in and we can use it from there
3. we can use "labels" to make exemptions ("allow to modify translations" for example) rather than commit "exemptions file". How it works (we do it already) - we need to set a specified label on the PR to skip the check for modified translations. So rather than finding out how to modify exemptions files,a committer has to deliberately set "allow to modify translations") to let the PR pass the selective checks.
4. you can unit test is with test_selective_checks.py

It's also very easy to test:

breeze ci selective-checks --commit-ref <HASH> --pr-labels "label"`

We do it already a very similar way if suspended providers are affected:

https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L1376

Some pointers how we can do it:

• add a new property in SelectiveChecks "english_translation_affected" (it will be automatically converted into output in GitHubActions
• make it return true if "en" translations are in "changed files" https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L144
• in the property method check a constant (True) in this commit "FAIL_IF_EN_TRANSLATION_MODIFIED" (for now - we can set to False when we want to disable the check) and sys.exit(1) with the right error message if en translation is in changed files unless "allow to modify translations" label is set (similarly as we do in https://github.com/apache/airflow/blob/main/dev/breeze/src/airflow_breeze/utils/selective_checks.py#L884

[Lee-W]

sounds like a good idea 🤔

[shahar1]

Thanks for the feedback, Jarek! As we discussed on Slack, converting it into a selective check would be a follow up :)

[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 4579a38 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]

The simpler freeze here #55154