shahar1 commented on code in PR #51292: URL: https://github.com/apache/airflow/pull/51292#discussion_r2124412383
########## airflow-core/src/airflow/ui/src/i18n/README.md: ########## @@ -17,8 +17,188 @@ under the License. --> -Checking completeness of i18n files: ------------------------------------- +# 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. +- Individuals 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. + + +## 2. Definitions + +**i18n** - Internationalization, the process of designing a software application so that it can be adapted to various languages and regions without engineering changes. + +**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 individual 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. + +**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. + +## 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. Requirements + +### 4.1. Translation ownership and code ownership + +Each supported translation, except for the default language, MUST meet one of the following conditions at any given time (except for transition times in section 6.4.): + +- 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. + +### 4.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, 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 a Apache Airflow committer who will act as a translation sponsor. +- Translation owners candidates MUST go through the approval process detailed in section 6.1. + +### 4.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. + +### 4.4. Resolution of translation conflicts + +Translation conflicts MUST be resolved according to the procedures outlined in section 6.3. + +### 4.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**. + +> [!NOTE] +> Tooling for detecting missing translations is available (see Tools & Resources section below). + +### 4.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. + +### 4.7. Approval 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. + +## 5. Roles & responsibilities + +### 5.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 issues and discussions. Review Comment: Here I actually meant GitHub issues :) Anyway, the neutral tone is implied from the quality standards mentioned in the beginning -- 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]
