bugraoz93 commented on code in PR #51292: URL: https://github.com/apache/airflow/pull/51292#discussion_r2125076714
########## airflow-core/src/airflow/ui/src/i18n/README.md: ########## @@ -17,8 +17,212 @@ under the License. --> -Checking completeness of i18n files: ------------------------------------- +# Internationalization (i18n) Policy + +## 1. Purpose & 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. +The scope of this policy is applied to: + +- Each supported language included in the `airflow-core/src/airflow/ui/src/i18n/locales` directory of the Apache Airflow project, or any suggested new translation. +- Contributors responsible for maintaining these translations by any of the roles defined below. +- Contributors who apply changes in the default language (English) that may affect translations. + +> [!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)). + +**Supported translation** - A translation that has been officially accepted into the project, located in `airflow-core/src/airflow/ui/src/i18n/locales`. + +**Default language** - The language used by default, and as a fallback to all other languages (English). + +**Translation owner** - A designated contributor responsible for the maintenance and quality for a supported translation. + +**Code owner** - An Apache Airflow committer designated in the `.github/CODEOWNERS` file for a supported translation. Only Code owners have write permissions to the repository and can be listed in `.github/CODEOWNERS`. + +**Translation sponsor** - An Apache Airflow committer who supports a non-comitter translation owner (e.g., by merging Pull Requests on their behalf). + +**Engaged translator** - An Apache Airflow contributor who actively participates in the translation process, yet is not a translation owner. + +**Release manager** - according to the definition in the [Release Management Policy](../../../../../../dev/README_RELEASE_PROVIDERS.md#what-the-provider-distributions-are). + +**Dev. list** - The Apache Airflow development mailing list: [email protected]. + +**Inactive translation/code owner** — A translation owner/code owner is considered inactive if they meet either of the following criteria: + +- The translation under their responsibility has remained incomplete for at least two consecutive releases. +- They have not participated in the Apache Airflow project for more than 12 months. + +## 3. Wording/Phrasing + +- Unless specified explicitly, references to directories and files in the document refer to files 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 the RFC 2119. + +## 4. Roles & responsibilities + +### 4.1. Translation owner + +- Translation owners are responsible for the following, in their assigned supported translation, according to established quality standards and procedures stated below: + - Ensuring translation remains up-to-date with source code changes in the default language. + - 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. + +### 4.2. Code owner + +- Code owners are responsible for the following, in their assigned supported translation, 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 needed. + - Managing translation-related GitHub issues and discussions, when needed (e.g., closing issues). +- Translations sponsors who function as code owners, are also responsible for ensuring that the translation owner is active and able to maintain the translation. If not, they should act according to section 6.4. + +### 4.3. Engaged translator + +- Engaged translators do not have any formal responsibilities, but they are encouraged to contribute to translations by: + - Suggesting improvements to existing translations. + - Reporting issues or inconsistencies in translations. + - Participating in discussions related to translations. + - Assisting translation owners with their tasks, when needed. + - Being 3rd party reviewers for translation-related PRs and conflicts, when needed. +- They 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. + +## 5. Requirements + +### 5.1. Translation ownership and code ownership + +Each supported translation, except for the default language, MUST meet one of the following conditions: + +- Have at least one translation owner who is also a code owner. +- Have at least one translation owner, with a translation sponsor assigned as a code owner. + +> [!NOTE] +> It is welcomed and desired to have more than one individual translation owner to enable peer reviews and provide coverage during individual absences. + +### 5.2. Approval of translation owners candidates + +- Translation owners candidates MUST declare and demonstrate a sufficient level of proficiency in the target language for translation purposes (as detailed in section 6.5), including technical terminology. +- 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. +- Translation owners candidates MUST go through the approval process detailed in section 6.1. + +### 5.3. Approval of new translations + +To accept a new translation to the codebase, it MUST be approved through a review process discussed in section 6.2. + +### 5.4. Resolution of translation conflicts + +Translation conflicts MUST be resolved according to the procedures outlined in section 6.3. + +### 5.5. Adding / rephrasing terms + +- When new terms are added to the default language, all translation owners SHOULD create a follow-up PR to comply with the changes in their assigned language within a reasonable time. +- When rephrasing terms in the default language, all translation owners SHOULD do the same as above, **if needed**. +- In busy times with many parallel UI changes it is acceptable to batch changes together, latest prior a release the differences SHOULD be cleared. + +> [!NOTE] +> Tooling for detecting missing translations is available (see Tools & Resources section below). + +### 5.6. Deprecating / refactoring terms + +When existing terms are deprecated or refactored (key renamed/relocated but value unchanged), **the contributor initiating the change is responsible for updating all language files, and not the translation/code owner**. Automation through Breeze tooling should be used when available. + +### 5.7. Approval and merging of translation-related Pull Requests (PRs) + +- If the code owner is also a translation owner of the respective translation: + - Others' PRs should be approved and merged normally by them. + - Their own PRs should be approved and merged normally by another committer, preferably another code owner in their locale (if such exists). +- Otherwise, if the code owner is sponsored: + - They should merge the translation-related PRs only after they are approved by the translation owner. +- Other committers may review and approve translation-related PRs in any aspects, but they SHOULD NOT merge them without the approval of the translation owner and the consent of the code owner. +- Before merging a translation-related PR, the translation should be checked for completeness using the provided tools (see section 8). + +> [!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). + +### 5.8. Version release + +- Requirements for release managers are defined in the [Release Management Policy](../../../../../../dev/README_RELEASE_AIRFLOW.md). + + +## 6. Procedures + +### 6.1. Approval process of a translation owner + +- The designated code owner should post a thread in the dev. list to request for approval of the translation owner(s) for a supported translation: Review Comment: Maybe we should also include sponsors to the thread and await approval from the sponsor in addition to binding votes rather than commenting in the Github? Just and idea not a blocker -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
