This is an automated email from the ASF dual-hosted git repository.
choo121600 pushed a commit to branch v3-2-test
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/v3-2-test by this push:
new 113052162eb [v3-2-test] Simplify i18n policy (#65630) (#65678)
113052162eb is described below
commit 113052162eb07ad83a12cd64c6dba9f930350254
Author: github-actions[bot]
<41898282+github-actions[bot]@users.noreply.github.com>
AuthorDate: Thu Apr 23 01:30:10 2026 +0900
[v3-2-test] Simplify i18n policy (#65630) (#65678)
* Simplify i18n policy
* Add a locale-specific translation guide file
* Fix header typo
* Replace 'active reviewer' with 'translation owner'
* committers -> committers'
* 'descides'->'resolves'
* Update review and merge expectations
* Add communications section
* Add missing parts
(cherry picked from commit e3af47b7740030704b14a2b7680c9b2ce7101332)
Co-authored-by: Shahar Epstein <[email protected]>
---
.pre-commit-config.yaml | 1 +
airflow-core/src/airflow/ui/public/i18n/README.md | 446 +++++++---------------
dev/README_RELEASE_AIRFLOW.md | 76 +---
3 files changed, 144 insertions(+), 379 deletions(-)
diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml
index 3c879b5fc64..a6070c5b25c 100644
--- a/.pre-commit-config.yaml
+++ b/.pre-commit-config.yaml
@@ -587,6 +587,7 @@ repos:
^README\.md$|
^pyproject\.toml$|
^generated/PYPI_README\.md$|
+ ^airflow-core/src/airflow/ui/public/i18n/README\.md$|
^airflow-core/docs/.*commits\.rst$|
^airflow-core/newsfragments/41368\.significant\.rst$|
^airflow-core/newsfragments/41761.significant\.rst$|
diff --git a/airflow-core/src/airflow/ui/public/i18n/README.md
b/airflow-core/src/airflow/ui/public/i18n/README.md
index c4a269bf8ed..3c16ef0cf35 100644
--- a/airflow-core/src/airflow/ui/public/i18n/README.md
+++ b/airflow-core/src/airflow/ui/public/i18n/README.md
@@ -19,387 +19,213 @@
# Internationalization (i18n) Policy
-## 1. Purpose & scope
+## Purpose and scope
-This document outlines the policy for internationalization (i18n) in Apache
Airflow, detailing the lifecycle
-of translations within the project.
-This policy aims to avoid inconsistencies, maintenance issues, unclear
ownership, and to ensure translation
-quality.
+This document defines the minimal policy for UI translations in Apache Airflow
core. It exists to keep
+translations maintainable, reviewable, and consistent without adding
unnecessary process.
-### Scope
+It applies to:
-This policy applies to:
-
-- Each supported locale included in
`airflow-core/src/airflow/ui/public/i18n/locales`.
-- Contributors making changes in the default locale (English).
-- Contributors suggesting new locales to be added to the codebase.
-- Maintainers of supported locales in any role defined below.
-- Committers and PMC.
-- Release managers.
+- All supported locales in `airflow-core/src/airflow/ui/public/i18n/locales`.
+- Contributors changing the default locale (`en`).
+- Contributors proposing a new supported locale.
+- Translation owners, code owners, and committers reviewing
translation-related PRs.
> [!NOTE]
-> This policy currently applies only to changes made in Apache Airflow core,
as i18n is not yet implemented
-> for providers (including auth managers). When such support is added, this
policy should be updated to reflect
-> the expanded scope.
-
-## 2. Definitions
-
-**Internationalization (i18n)** - The process of designing a software
application so that it can be adapted to
-various languages and regions without engineering changes (see also
-the [Wikipedia
article](https://en.wikipedia.org/wiki/Internationalization_and_localization)).
+> This policy currently applies only to Airflow core UI translations.
-**Supported locale** - An officially accepted locale in
`airflow-core/src/airflow/ui/public/i18n/locales`.
+## Core terms
-**Default locale** - English (`en`), the primary locale and fallback for all
other locales.
+- **Default locale**: English (`en`), the source and fallback for all other
locales.
+- **Supported locale**: A locale that is present in the repository and listed
in the UI configuration.
+- **Translation owner**: The person responsible for language quality and
ongoing maintenance of a supported locale.
+- **Code owner**: The committer responsible for technical review and merge
decisions for that locale.
+- **Translation sponsor**: A committer supporting a non-committer translation
owner.
+- **Complete translation**: A locale that covers at least 90% of the terms in
the default locale.
+- **Inactive owner**: A translation owner or code owner who is no longer
actively maintaining the locale, for
+ example because they have not contributed to Airflow for more than 12 months
or the locale has remained
+ incomplete for two consecutive major or minor releases.
-**Translation owner** - Designated contributor responsible for maintaining a
supported locale.
+## Ownership
-**Code owner** - Apache Airflow committer with write permissions, listed in
`.github/CODEOWNERS`.
+Each supported non-English locale must have:
-**Translation sponsor** - Apache Airflow committer supporting a non-committer
translation owner (e.g., by
-communicating in the dev list or merging Pull Requests on their behalf).
+- At least one translation owner.
+- At least one code owner listed in `.github/CODEOWNERS`.
-**Engaged translator** - Active contributor participating in translation
without formal ownership.
+A single committer may serve in both roles. When the translation owner is not
a committer, a committer must
+act as translation sponsor.
-**Complete translation** - A supported locale is considered complete when it
covers at least 90% of the terms in the default locale.
+Translation owners are responsible for language quality, consistency, and
keeping the locale reasonably current.
+Code owners are responsible for technical review, merge decisions, and making
sure the locale still has active
+maintainers.
-**Inactive owner** — Either a translation owner or a code owner might be
considered inactive if they meet any of
-the following criteria:
+Having more than one translation owner for a locale is recommended, but not
required.
-- The locale under their responsibility has remained incomplete for at least 2
consecutive major/minor releases.
-- They have not contributed to Apache Airflow for more than 12 months.
-- Code owners specifically might be considered inactive according to any other
terms mentioned in the
- ["Committers and PMC
Members"](../../../../../../COMMITTERS.rst#inactive-committers) document.
+## Communication
-**Dev list** - The Apache Airflow development mailing list:
[email protected].
+Translation-related decisions that affect supported locales, ownership, or
policy should happen in public
+through the dev list.
-## 3. Wording/Phrasing
+Locale owners and other regular translation contributors should also join the
`#i18n` Slack channel for
+day-to-day coordination and for release-time notifications about last-minute
string changes.
-- Unless explicitly stated otherwise, all references to directories and files
in this document pertain to
- those in the `main` branch.
-- Where emphasised by capital letters, the keywords "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "
- SHOULD",
- "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in
- RFC 2119.
+## Adding or removing a supported locale
-## 4. Roles & responsibilities
+### Adding a locale
-### 4.1. Translation owner
+A new locale may be added when all of the following are true:
-- Translation owners are responsible for the following, in their assigned
supported locale, according to the
- established quality standards and procedures stated below:
- - Ensuring locale remains up-to-date with source code changes in the default
locale.
- - Reviewing the language aspects of translation-related Pull Requests (PRs).
- - Resolving translation-related conflicts in PRs.
- - Ensuring translation reflects current language usage and terminology.
- - Resolving translation-related GitHub issues and discussions.
+- The locale has an identified translation owner and code owner.
+- The ownership arrangement has been approved through the dev list process
described below before merge.
+- The locale is added to the repository and UI configuration.
+- The locale follows the translation guidance in this document and the
locale-specific guide, if one exists.
-### 4.2. Code owner
+The PR for a new locale should include:
-- Code owners are responsible for the following, in their assigned supported
locale, according to the
- procedures stated below:
- - Reviewing the technical aspects of translation-related PRs (e.g., linting,
formatting, etc.).
- - Merging translation-related PRs approved by the translation owner.
- - Resolving translation-related conflicts in PRs, when there's a conflict
between translation owners.
- - Managing translation-related GitHub issues and discussions, when needed
(e.g., closing GitHub issues).
-- Code owners who act as translation sponsors are also responsible for:
- - Ensuring that the translation owner is active and able to maintain the
translation.
- - Act according to section 6.4 when the translation owner relinquishes their
role or becomes inactive.
- - When they sponsor a single translation owner, without additional
translation owners/engaged translators involved,
- they SHALL also review the language aspects of translation-related PRs
using a trusted third-party opinion (e.g., LLM).
+- A locale-specific translation guide file at
`.github/skills/airflow-translations/locales/<locale>.md`
+- Locale files under
`airflow-core/src/airflow/ui/public/i18n/locales/<locale>`.
+- Updates to `airflow-core/src/airflow/ui/src/i18n/config.ts`.
+- Updates to `dev/breeze/src/airflow_breeze/commands/ui_commands.py`.
+- Updates to `.github/CODEOWNERS`.
+- Updates to the table at the bottom of this file.
-### 4.3. Engaged translator
+### Relinquishing translation/code ownership
-- Engaged translators do not have any formal responsibilities, but they are
encouraged to contribute to
- supported locales by:
- - Suggesting improvements.
- - Reviewing PRs.
- - Reporting issues or inconsistencies in translations.
- - Participating in discussions related to translations.
- - Assisting translation owners with their tasks.
- - Being 3rd party reviewers for translation-related conflicts, when needed.
-- Engaged translators may be mentioned in a comment in the
`.github/CODEOWNERS` file.
-- Suitable candidates for translation ownership may be suggested from engaged
translators, upon their consent
- and approval by the procedure in section 6.1.
+- When a code owner asks to relinquish their role, or they become inactive,
any other committer should:
-## 5. Requirements
+ - Raise a PR for removal of the previous code owner from the
`.github/CODEOWNERS` file.
+ - Post a thread in the dev list that they step in as the code owner.
-### 5.1. Translation ownership and code ownership
+- When a translation owner asks to relinquish their role, or they become
inactive, and there are no other active translation owners, the code owner
should:
-- Each supported locale, except for the default language, MUST have at least
one translation owner and at
- least one code owner assigned at all times, with these considerations:
- - Ownership for both roles MUST be approved according to the process
discussed in section 6.1.
- - A single Apache Airflow committer MAY serve as both code owner and
translation owner for the same locale.
- - If none of the translation owners are code owners - there MAY be a
translation sponsor assigned as a code
- owner.
-- When the above is not met, steps mentioned in section 6.4 SHOULD be taken by
the appropriate roles.
+ - Raise a PR for removal of the translation owner from the
`.github/CODEOWNERS` file.
+ - Post a thread in the dev list that they are looking for assigning someone
else as the translation owner within 30 days.
+ - If a replacement is found within this time, they should be approved
according to the ownership approval procedure below.
+ - Otherwise, the code owner should raise a vote in the dev list for the
removal of the translation from the codebase, with PMC and committers' votes
counted as binding.
- > [!WARNING]
- > It is preferred to have at least two translation owners, or at least one
translation owner and another engaged translator,
- > to allow peer reviews and provide coverage during absences.
- > Specifically, when translation is sponsored and there's only a single
translation owner, without additional proficient people involved, the code
owner becomes responsible for reviewing language aspects of PRs
- > using a third-party opinion, which could risk quality and timeliness of
reviews.
+## Procedures
-### 5.2. Adding new locales
+### Approval of ownership candidates
-To accept a new supported locale to the codebase, it MUST be approved through
the process discussed in section
-6.2.
+- The designated code owner should post a thread to the dev list that includes
the following details:
+ - The locale being suggested, including a link to the PR.
+ - Designated code owner(s) and translation owner(s) in the suggested locale.
+ - If the code owner is sponsored, they should indicate this as well.
Specifically, if there is only one translation owner, the code owner should
also declare how they plan to approve the language aspects of PRs.
+- Within the thread, the code owner should demonstrate that the translation
owner is suitable for the role,
+ including sufficient proficiency in the target language and, for
non-committers, the ability to maintain
+ translation files through the normal PR process.
+- Approval of any translation owner who is not a committer requires at least
one binding vote of 1 PMC member, and no objections from other committers or
PMC.
+- Approval of any translation owner who is also a code owner (committer) does
not need to be voted on.
-### 5.3. Translation owners candidates
+## Expectations for translation changes
-- Translation owners candidates MUST declare and demonstrate a sufficient
level of proficiency in the target
- language for translation purposes, including technical terminology (as
detailed in section 6.5).
-- Translation owners candidates, who are non-committers, MUST also meet the
following criteria:
- - They are active long-term contributors to the Apache Airflow project at
the time of request.
- - They have basic skills of working with Git and GitHub, as well as
modifying JSON translation files within
- their target language.
- - They have the support of an Apache Airflow committer who will act as a
translation sponsor.
-
-### 5.4. Resolution of translation conflicts
-
-Translation conflicts MUST be resolved according to the procedures outlined in
section 6.3.
-
-### 5.5. Adding or rephrasing terms
-
-- When new terms are added to the default locale, all translation owners
SHOULD create a follow-up PR to
- comply with the changes in their assigned locale.
-- When existing terms are rephrased in the default language (key is the same
but value changed), all
- translation owners SHOULD do the same as above.
-- As the change of the default language might be un-noticed by translators
(translation keys would stay valid)
- it is recommended to rename the translation key to force a detection of
language gaps (translations would
- have 1 orphan (old) key and a missing (new) key).
-- In busy times with many parallel UI changes it is acceptable to batch
changes together. Differences SHOULD
- be cleared prior to a release at the latest.
+### Default locale changes
-> [!NOTE]
-> Tooling for detecting missing terms is available (see Tools & Resources
section below).
+English is the source of truth. When contributors add, rename, or
substantially rephrase English terms, they
+should make downstream translation work easy.
-### 5.6. Deprecating / refactoring terms
+- New or materially changed strings should be easy to detect in other locales.
+- If a key is rephrased significantly, renaming the key is preferred so
missing translations are visible.
+- If a key is only moved or renamed without changing meaning, the contributor
making that refactor should update
+ the locale files rather than leaving cleanup to translation owners.
+- In some cases, it may be more cost-effective to update the non-English
locales in the same PR as the default-locale change, for example by using
LLM-assisted translation. In that case, separate explicit approval from
translation owners or code owners for each locale update is not required.
-- When existing terms are deprecated or refactored in the default locale (key
renamed/relocated but value
- unchanged), **the contributor initiating the change is responsible for
updating all relevant locale
- files, and not any of the locale's owners**. When such is available,
automation through Breeze tooling SHOULD
- be used.
+### Non-Default locale changes
-### 5.7. Merging of translation-related Pull Requests (PRs)
+Translations should:
-- Before merging any translation-related PR, it MUST be:
- - Approved by a translation owner of the respective locale for language
aspects, according to the standards
- and guidelines.
- - When a translation owner initiates a PR and is the only one assigned to
the locale, they SHOULD instead
- ask for approval from a third party (e.g., engaged translator), or if
such is not available, declare
- their self-approval for the language aspects.
- - Approved by a code owner, or another committer on their behalf, for
technical aspects (e.g., linting,
- formatting, etc.).
-- Before merging a translation-related PR, the translation SHOULD be checked
for completeness using the
- provided tools (see section 8).
+- Preserve the meaning and intent of the English source.
+- Keep technical terminology consistent.
+- Preserve placeholders, formatting, and interpolation variables.
+- Follow local language conventions without changing product behavior.
+- Stay at or above the completeness threshold over time.
-> [!WARNING]
-> In languages with different word order than English, or in Right-To-Left
(RTL) languages, it is important to
-> validate that the changes are properly reflected in the UI.
-> If they are not, please raise a GitHub issue or a PR for fixing it
(separately from the translation PR).
+Locale-specific guideline files take precedence over the general guidance in
this document.
-### 5.8. Version release
+> [!CAUTION]
+> Translation content must comply with the Apache Airflow Code of Conduct.
-- Release managers MUST follow the requirements for releasing changes in
supported locales defined in
- the [Release Management
Policy](../../../../../../dev/README_RELEASE_AIRFLOW.md).
+## Review and merge expectations
-## 6. Procedures
+Before merging a translation-related PR:
-### 6.1. Approval of ownership candidates
+- Language changes should be approved by a translation owner for that locale.
+- Technical changes may be approved and merged by any committer. However, the
code owner has an added responsibility for the locale, so it is preferable to
involve them.
+- Completeness should be checked with the available tooling.
-- The designated code owner should post a thread to the dev list that includes
the following details:
- - The locale being suggested, including a link to the PR.
- - Designated code owner(s) and translation owner(s) in the suggested locale.
- - If the code owner is sponsored, they should indicate this as well.
Specifically, if there is only one translation owner, the code owner should
also declare how they plan to approve the language aspects of PRs (e.g., an
engaged translator, LLM, etc.).
-- Within the thread, the code owner should demonstrate that the translation
owner is suitable for the role,
- according to the requirements in section 5.3.
-- Approval of any translation owner who is not a committer requires at least
one binding vote of 1 PMC member,
- and no objections from other committers/PMC.
-- Approval of any translation owner who is also a code owner (committer) does
not need to be voted on.
+If a locale has only one translation owner and that person authors the PR, an
additional reviewer is preferred.
+When that is not practical, the code owner may use a trusted third-party
review method, including LLM-assisted
+review, before merging (for example, GitHub Copilot or Claude).
-### 6.2. Approval of a new locale
-
-The following steps outline the process for approving a new locale to be added
to the supported locales:
-
-- Creating a PR for adding the suggested locale to the
- codebase ([see
example](https://github.com/apache/airflow/pull/51258/files)), which includes:
- - Adding the plural form rules for the suggested locale under
`PLURAL_SUFFIXES` constant in
- `dev/breeze/commands/ui_commands.py`.
- - The locale files (translated according to the guidelines) in the
- `airflow-core/src/airflow/ui/public/i18n/locales/<LOCALE_CODE>` directory,
where `<LOCALE_CODE>` is the
- code of the language according to ISO 639-1 standard (e.g., `fr` for
French). Languages with regional
- variants should be handled in separate directories, where the name is
suffixed with `-<VARIANT>`, and
- `<VARIANT>` is the variant that follows ISO 3166-1 or UN M.49 codes in
lowercase (e.g., `zh-tw` for
- Taiwanese Mandarin).
- - Making the required modifications in
- `airflow-core/src/airflow/ui/src/i18n/config.ts` ([see
example](https://github.com/apache/airflow/pull/51258/files#diff-bfb4d5fafd26d206fb4a545a41ba303f33d15a479d21e0a726fd743bdf9717ff)).
- - Changes to the `.github/CODEOWNERS` file to include the designated code
owner(s) and translation owner(s)
- for the new locale, considering the following:
- - A code owner who is also a translation sponsor should be indicated in a
comment as well.
- - If the PR author is neither eligible nor willing to become both of these
roles, they should suggest
- relevant candidates for the missing role(s), or call for volunteers.
-- Applying the procedure in section 6.1. to approve the identities of the code
owner(s) and the translation
- owner(s).
-- Only after the steps above are completed, the PR for the new translation may
be merged (by the requirements
- in section 5.7).
-- Translation owners and code owners for the new locale SHOULD add themselves
to the `#i18n` channel of
- Airflow slack - during freeze time this is where notification about new
"last-minute" changes to translation
- files will be published, also it's a great platform to collaborate and share
internationalization tips and
- tricks.
-
-### 6.3. Translation conflict resolution
-
-When a translation conflict arises in a locale-related PR, the following steps
will be taken in order:
-
-- The involved parties should first try to reach a consensus through
discussion in the PR.
-- If no consensus is reached, a translation owner may decide the outcome.
-- If multiple translation owners are involved and cannot reach consensus, the
code owner will decide. If the
- code owner is sponsored,
- they should base their decision on a neutral source (e.g., a third-party
opinion, translation tool, or LLM).
-- If the conflict is between code owners, a PMC member will be involved to
resolve the conflict.
-
-### 6.4. Relinquishing translation/code ownership
+When review relies on a single translation owner together with a translation
sponsor, the code owner should use
+a trusted neutral third-party opinion for language questions when needed.
-- When a code owner asks to relinquish their role, or they become inactive,
any other committer should:
- - Raise a PR for removal of the previous code owner from the
`.github/CODEOWNERS` file.
- - Post a thread in the dev list that they step in as the code owner (either
as a translation sponsor, or a
- translation owner according to steps discussed in section 6.1).
-- When a translation owner asks to relinquish their role, or they become
inactive, and there are no other
- active translation owners, the code owner should:
- - Raise a PR for removal of the translation owner from the
`.github/CODEOWNERS` file.
- - Post a thread in the dev list that they are looking for assigning someone
else as the translation owner
- within 30 days.
- - If a replacement is found within this time, they should be approved
according to section 6.1.
- - Otherwise, the code owner should raise a vote in the dev list for the
removal of the translation from the
- codebase (7 days vote, PMC and committers votes are counted as binding).
+When a translation dispute cannot be resolved in the PR discussion:
-### 6.5 Demonstrating language proficiency
+- A translation owner resolves language questions for their locale.
+- If multiple translation owners disagree, the code owner decides, using a
trusted neutral third-party opinion
+ when needed.
+- If code owners disagree, a PMC member should be involved to resolve the
conflict.
-Language proficiency for translation owners can be demonstrated through any of
the following means:
+For RTL languages, languages with significantly different word order, or
languages that typically require much longer text, a UI check is strongly
recommended in addition to file-level review.
-- Communications in open-source projects, social media, mailing lists, forums,
or any other platforms in the
- target language.
-- Direct communication with a proficient committer in the target language.
-- Official language certifications (this is not a mandatory requirement).
+## Tools
-## 7. Standards & guidelines
-
-> [!CAUTION]
-> Usage of language that defies Apache Airflow's [code of
conduct](http://airflow.apache.org/code-of-conduct/)
-> is prohibited in any circumstances.
-
-- Translations should be based on the default language (English). When
translating a language that has already
- a similar translation supported
- (e.g., Portuguese vs. Spanish), the other language might be used as a
reference, but still the default
- language (English) should be the primary source for translations.
-- Translations should be accurate, maintaining original meaning and intent.
-- Translations should be complete, covering all terms and phrases in the
default language up to the defined
- completeness threshold.
-- Translation of technical terminology should be consistent (for example: Dag,
Task, Operator, etc.).
-- Language should be polite and neutral in tone.
-- Local conventions should be considered (e.g., date formats, number
formatting, formal vs. informal tone,
- etc.).
- - In case that local conventions requires deviation from any of these
guidelines, exceptions may be
- requested via PR or a thread in the dev list.
-- Formatting, placeholders, and variable substitutions must be preserved.
-
-## 8. Tools & resources
-
-### 8.1. Checking completeness of i18n files
-
-All files:
+Check completeness for all locales:
```bash
breeze ui check-translation-completeness
```
-> [!NOTE]
-> When announcing a freeze time, copy the output of the table showing
completeness of all languages
-> to the mail body.
-
-Files for specific languages:
+Check a specific locale:
```bash
breeze ui check-translation-completeness --language <language_code>
```
-Where `<language_code>` is the code of the language you want to check, e.g.,
`en`, `fr`, `de`, etc.
-
-Adding missing translations (with `TODO: translate` prefix):
+Add missing entries for a locale:
```bash
breeze ui check-translation-completeness --language <language_code>
--add-missing
```
-You can also remove unused translations from the language of your choice:
+Remove unused entries for a locale:
```bash
breeze ui check-translation-completeness --language <language_code>
--remove-unused
```
-Or from all languages:
+Remove unused entries for all locales:
```bash
breeze ui check-translation-completeness --remove-unused
```
-
-## 9. Compliance & enforcement
-
-> [!NOTE]
-> As of the time of writing, this policy is not enforced by any automated
checks.
-> The following describe the desired future state of compliance and
enforcement.
-
-- Automated checks SHOULD verify once in a while that all languages have
corresponding entries for new terms
- in the default language. When translations are missing, relevant code owners
should be notified.
-- Automated checks SHOULD allow a person doing translation to select the
language and aid them in adding new
- translations so that they do not have to compare them manually. Possibly it
can be done by adding
- `-–add-missing` to the verifying script that will add new entries with
`TODO: translate: ENGLISH VERSION`
- and add prek hook to not allow such `TODO:` entries to be committed.
-
-## 11. Freeze time
-
-A few weeks before a minor or major release, a freeze time for accepting new
translations, might be announced in the dev list by the Release Manager.
-It should be announced when the median coverage across all translations is
below the completeness threshold (90%), or when needed (e.g., due to a critical
UI feature that requires many new terms to be added).
-It will be announced in the dev list about two weeks before it starts, to
allow time for preparing, and it should last until median completeness is back
above the threshold, or RC is cut for the release (whichever is earlier).
-
-During that freeze time there should be no changes applied to the default
language (English) locale files. When freeze time starts we set this variable
in the
-`dev/breeze/src/airflow_breeze/utils/selective_checks.py` file:
-
-```python
-FAIL_WHEN_ENGLISH_TRANSLATION_CHANGED = True
-```
-
-This fails any attempt to change English translation files in a PR unless
`allow translation change`
-label is applied to the PR. This still allows issues in the English
translation files to be fixed and
-deliberate updates to be made, while avoiding accidental changes.
-
-Any change in the English translation files during freeze time MUST be
communicated in the
-[#i18n](https://app.slack.com/client/TCQ18L22Z/C09D0A7FESJ?) Slack channel and
MUST be approved by at least 1 PMC member - so that translators can be informed
as early as possible about those translations
-being added.
-
-> [!NOTE]
-> The definition of completeness takes into account that some terms might be
added during freeze time and remain untranslated.
-
-### 11.1 Guidelines for approving freeze exemptions
-
-The following questions should be considered before approving exemptions for
changes to the English translation files during freeze time:
-
-- Are the changes necessary for a critical fix or feature?
-- Do the changes only introduce minor fixes to existing terms? (such
modifications are usually less disruptive and OK to approve)
-- Do the changes introduce new terms, remove terms, or significantly alter
already translated terms? (if so, it may be better to wait until the next
release)
-- Is it feasible to complete the translations in all locales before the
release? (the fewer changes, the more feasible)
-- If not all translations are completed before the release, will it
significantly affect the user experience? (if so, it might be better to wait
until the next release).
-- If not all translations are completed before the release, will any locales
be left in an incomplete state? (if so, it might be better to wait until the
next release).
-
-## 12. Exceptions
-
-If any exceptions to this policy are needed, they MUST be discussed and
approved by voting in the dev list
-beforehand.
-
-## 13. Review and updates
-
-This policy will be reviewed and updated as needed to ensure it remains
relevant and effective.
-Depending on the nature of the change, suggested updates might need to be
discussed and approved by voting in
-the dev list.
+## Locale-specific guidance
+
+Before translating, read the locale-specific guide if one exists. Those files
contain glossary and style choices
+for the target language and override the general guidance in this document
when there is a conflict. They are
+primarily intended for LLM-assisted translation work, but can also be used by
human contributors.
+
+| Locale Code | Language | Guideline File |
+| ----------- | ----------------------- | ------------------------------- |
+| `ar` | Arabic |
[.github/skills/airflow-translations/locales/ar.md](../../../../../../.github/skills/airflow-translations/locales/ar.md)
|
+| `ca` | Catalan |
[.github/skills/airflow-translations/locales/ca.md](../../../../../../.github/skills/airflow-translations/locales/ca.md)
|
+| `de` | German |
[.github/skills/airflow-translations/locales/de.md](../../../../../../.github/skills/airflow-translations/locales/de.md)
|
+| `el` | Greek |
[.github/skills/airflow-translations/locales/el.md](../../../../../../.github/skills/airflow-translations/locales/el.md)
|
+| `es` | Spanish |
[.github/skills/airflow-translations/locales/es.md](../../../../../../.github/skills/airflow-translations/locales/es.md)
|
+| `fr` | French |
[.github/skills/airflow-translations/locales/fr.md](../../../../../../.github/skills/airflow-translations/locales/fr.md)
|
+| `he` | Hebrew |
[.github/skills/airflow-translations/locales/he.md](../../../../../../.github/skills/airflow-translations/locales/he.md)
|
+| `hi` | Hindi |
[.github/skills/airflow-translations/locales/hi.md](../../../../../../.github/skills/airflow-translations/locales/hi.md)
|
+| `hu` | Hungarian |
[.github/skills/airflow-translations/locales/hu.md](../../../../../../.github/skills/airflow-translations/locales/hu.md)
|
+| `it` | Italian |
[.github/skills/airflow-translations/locales/it.md](../../../../../../.github/skills/airflow-translations/locales/it.md)
|
+| `ja` | Japanese |
[.github/skills/airflow-translations/locales/ja.md](../../../../../../.github/skills/airflow-translations/locales/ja.md)
|
+| `ko` | Korean |
[.github/skills/airflow-translations/locales/ko.md](../../../../../../.github/skills/airflow-translations/locales/ko.md)
|
+| `nl` | Dutch |
[.github/skills/airflow-translations/locales/nl.md](../../../../../../.github/skills/airflow-translations/locales/nl.md)
|
+| `pl` | Polish |
[.github/skills/airflow-translations/locales/pl.md](../../../../../../.github/skills/airflow-translations/locales/pl.md)
|
+| `pt` | Portuguese |
[.github/skills/airflow-translations/locales/pt.md](../../../../../../.github/skills/airflow-translations/locales/pt.md)
|
+| `th` | Thai |
[.github/skills/airflow-translations/locales/th.md](../../../../../../.github/skills/airflow-translations/locales/th.md)
|
+| `tr` | Turkish |
[.github/skills/airflow-translations/locales/tr.md](../../../../../../.github/skills/airflow-translations/locales/tr.md)
|
+| `zh-CN` | Simplified Chinese |
[.github/skills/airflow-translations/locales/zh-CN.md](../../../../../../.github/skills/airflow-translations/locales/zh-CN.md)
|
+| `zh-TW` | Traditional Chinese |
[.github/skills/airflow-translations/locales/zh-TW.md](../../../../../../.github/skills/airflow-translations/locales/zh-TW.md)
|
diff --git a/dev/README_RELEASE_AIRFLOW.md b/dev/README_RELEASE_AIRFLOW.md
index 96b5763f3aa..28a032e5770 100644
--- a/dev/README_RELEASE_AIRFLOW.md
+++ b/dev/README_RELEASE_AIRFLOW.md
@@ -100,7 +100,7 @@ The first step of a release is to work out what is being
included. This differs
### Validating completeness of locale files
Before cutting the release candidate (RC), you should verify the completeness
of all merged locale files.
-Generate a completeness output for all locale files – follow the instructions
in section 8.1 of the [internationalization (i18n)
policy](../airflow-core/src/airflow/ui/public/i18n/README.md#81-checking-completeness-of-i18n-files)
to do so.
+Generate a completeness output for all locale files by following the tooling
instructions in the [internationalization (i18n)
policy](../airflow-core/src/airflow/ui/public/i18n/README.md#tools).
#### Patch releases (v3-X-test branch)
@@ -144,8 +144,7 @@ When it is time to cut the RC:
#### Minor/Major releases
-If the median completeness across all supported languages is below 90%, or
upon other justifying circumstances (e.g., release of a critical UI feature),
you should consider skipping the following instructions and applying an i18n
translation freeze instead (see subsection below).
-Otherwise, you should announce the completeness status to the
[email protected] mailing list.
+For major and minor releases, announce the completeness status to the
[email protected] mailing list.
Subject:
@@ -170,14 +169,14 @@ After running the i18n completeness script, this is the
coverage state of all me
Code owners, translation owners, and engaged translators whose locales are
currently below 90% coverage are kindly asked to complete their translations
prior to the RC being cut.
This will help ensure that all languages included in the upcoming release
remain complete and consistent.
-Contributors are also encouraged to plan their PRs accordingly and avoid
introducing large sets of new English terms close to the release date, to
prevent unexpected translation work for code owners.
+Contributors are also encouraged to keep PRs small and avoid introducing large
sets of new English terms close to the release date, to reduce last-minute
translation work.
Important notes:
1. Locales that remain incomplete for two consecutive major or minor releases
may be removed from the project, according to the i18n policy.
-2. Any changes merged after the final release won't be included, and missing
terms will fall back to English.
+2. Any changes merged after the release is cut won't be included, and missing
terms will fall back to English.
3. Code owners are responsible for ensuring that their assigned locales reach
at least 90% coverage before the RC is cut.
4. Requests for assistance, coordination, or early heads-up on expected
terminology changes may be shared in the #i18n Slack channel.
-5. PRs introducing new translations may continue to be merged as usual,
provided that coverage remains complete by the RC date.
+5. PRs introducing translation updates may continue to be merged as usual
until the RC is cut.
Thanks for your cooperation!
<your name>
@@ -187,73 +186,12 @@ EOF
When it is time to cut the RC, you should:
1. Generate an additional completeness output:
- a. If there are incomplete locales that were also incomplete in the previous
major/minor release, please contact the code owner and ask them to act
according to section "Relinquishing translation/code ownership" in the i18n
policy (section 6.4).
+ a. If there are incomplete locales that were also incomplete in the previous
major/minor release, please contact the code owner and ask them to act
according to the [removing or replacing ownership
procedure](../airflow-core/src/airflow/ui/public/i18n/README.md#removing-or-replacing-ownership)
in the i18n policy.
b. If there are other incomplete locales, please write it as a reminder for
the next major/minor release.
2. Post the final completeness output on the same thread.
-### Applying an i18n translation freeze
-
-Before cutting the release candidate (RC), you may announce a freeze time to
allow translators to complete translations for the upcoming release.
-During the freeze time, no changes to the English locale file should be merged
(enforced by CI checks), except for approved exemptions (see below).
-In general, if the overall median coverage across all supported languages
stays above 90%, a freeze is not required. However, if significant changes are
introduced that lower the median coverage to or below this threshold, a freeze
period can help translators complete their work without being overloaded.
-When a freeze is used, it should remain in effect until the median coverage
reaches at least 90% again, or until the RC is cut, whichever comes first.
-The freeze should be announced at least two weeks before it starts, to allow
time for translators to get ready and for contributors to plan their PRs
accordingly.
-To prepare for the announcement, fetch the completeness output generated
earlier.
-The announcement should be sent via the [email protected] mailing list –
you may accompany it with a GitHub issue for tracking purposes.
-
-Subject:
-
-```shell script
-cat <<EOF
-[ANNOUNCEMENT] English Translation freeze for Airflow ${VERSION} RC starting
at <START_DATE>
-EOF
-```
-
-Body (assuming delegation to another committer):
-
-```shell script
-cat <<EOF
-Hey fellow Airflowers,
-
-I'm sending this message on behalf of the release managers.
-The release managers are planning to cut the Airflow ${VERSION} RC soon/by
<RELEASE_DATE>.
-
-After running the i18n completeness script, this is the coverage state of all
merged locales as of <CURRENT_DATE>:
-
-<OUTPUT_OF_I18N_COMPLETENESS_SCRIPT>
-
-To prevent overloading the translators and to ensure completeness of all
translations by the release, a freeze upon the English locale will be applied
starting <START_DATE>,
-and until the RC is cut.
-Code owners, translation owners, and engaged translators are asked to complete
the coverage of their assigned locales during this time.
-Contributors are also encouraged to plan their PRs accordingly, to avoid
modifying the English locale during the freeze time.
-
-Important notes:
-1. Locales that remain incomplete for two consecutive major or minor releases
may be removed from the project, according to the i18n policy.
-2. Any changes merged after the final release won't be included, and missing
terms will fall back to English.
-3. Any PR that modifies the English locale during the freeze time will fail CI
checks.
-4. Requests for exemptions should be communicated in the #i18n Slack channel,
and approved by at least 1 PMC member - guidelines for approval are available
in the i18n policy.
-5. PRs approved for an exemption will be labeled with `allow translation
change`, and then the relevant CI check will pass. Translators are encouraged
to complete the translations for the exempted terms during the freeze time.
-6. Merging PRs for adding new translations could be done during the freeze
time - designated code owners should validate that by the end of the freeze
time, the coverage of the suggested translation is complete.
-
-
-Thanks for your cooperation!
-<your name>
-EOF
-```
-
-When the freeze starts, you should merge a PR for setting the flag
`FAIL_WHEN_ENGLISH_TRANSLATION_CHANGED` to `True` in the file
[selective_checks.py](./breeze/src/airflow_breeze/utils/selective_checks.py).
-If the freeze gets extended beyond the originally announced date, you should
post an update on the same thread.
-When it is time to cut the RC, you should:
-
-1. Generate an additional completeness output:
- a. If there are incomplete locales that were also incomplete in the previous
completeness output, please contact the code owner and ask them to act
according to section "Relinquishing translation/code ownership" in the i18n
policy (section 6.4).
- b. If there are other incomplete locales, please write it as a reminder for
the next major/minor release.
-2. Create a PR for setting the flag back to `False`.
-3. Post on the same thread that the freeze is lifted, and share the final
completeness output.
-
> [!NOTE]
-> Release managers - do not hold the release process beyond the due date if
there are still incomplete locales after the freeze.
-> It is the responsibility of code owners to ensure the completeness of their
locales by the due date.
+> The release process should not be blocked solely because some locales remain
incomplete at RC cut time. Missing translations fall back to English, and
incomplete locales should be followed up after the release.
## Selecting what to cherry-pick
