airflow-translations

โดย astronomer

เพิ่มหรืออัปเดตคำแปลสำหรับอินเทอร์เฟซผู้ใช้ของ Apache Airflow แนะนำการตั้งค่าภาษา การสร้างไฟล์คำแปล การแปลตามภาษาเฉพาะ...

npx skills add https://github.com/astronomer/airflow --skill airflow-translations

Airflow Translations

Determining the Task

Translation work falls into one of two categories depending on whether the target locale already exists. Check if a directory for the locale exists under airflow-core/src/airflow/ui/public/i18n/locales/<locale>/. If it does, skip ahead to Updating an Existing Translation. If not, start with Adding a Translation below.


Adding a Translation

When adding a translation, some configuration files need to be updated before translation work can begin.

Setting up the locale

First, create the locale directory:

mkdir -p airflow-core/src/airflow/ui/public/i18n/locales/<locale>/

Then update the following configuration files, keeping the existing alphabetical ordering in each file:

airflow-core/src/airflow/ui/src/i18n/config.ts: add the locale to the supportedLanguages array:

{ code: "<locale>", name: "<native name>" },

dev/breeze/src/airflow_breeze/commands/ui_commands.py: add the plural suffixes for the language to the PLURAL_SUFFIXES dict. Check the i18next plural rules for the language at https://jsfiddle.net/6bpxsgd4 to determine which suffixes are needed:

"<locale>": ["<suffixes>"],

.github/boring-cyborg.yml: under labelPRBasedOnFilePath, add:

translation:<locale>:
  - airflow-core/src/airflow/ui/public/i18n/locales/<locale>/*

Scaffolding the translation files

Once the configuration is in place, run the breeze command to copy every English namespace file into the new locale directory. This populates each key with a TODO: translate: stub:

breeze ui check-translation-completeness --language <locale> --add-missing

The generated files will look like this:

{
  "allRuns": "TODO: translate: All Runs",
  "blockingDeps": {
    "dependency": "TODO: translate: Dependency",
    "reason": "TODO: translate: Reason"
  }
}

Translating

With the scaffolded files in place, read the locale-specific guideline for the target language (see the table under Locale-Specific Guidelines below). If one exists, it contains the glossary, tone rules, and formatting conventions that must be followed. If no locale-specific guideline exists yet, follow the translation rules described later in this document.

Replace every TODO: translate: <English terminology> entry, including the prefix, with the translated string.

After all entries are translated, continue to Validation below.


Updating an Existing Translation

When a locale already exists and you need to fill translation gaps, revise existing translations, or remove stale keys, start by reading the locale-specific guideline for the language (see the table under Locale-Specific Guidelines below). This establishes the glossary and formatting rules to follow.

Next, read the locale's existing JSON files under airflow-core/src/airflow/ui/public/i18n/locales/<locale>/ to learn the terminology already in use. Consistency with established translations is critical. If a term has been translated a certain way, reuse that exact translation.

Then check the current state of completeness:

breeze ui check-translation-completeness --language <locale>

If there are missing keys, scaffold them with TODO: translate: stubs:

breeze ui check-translation-completeness --language <locale> --add-missing

If there are unused keys — keys that are not required, meaning they are absent from the English locale or are plural suffixes this language does not need — remove them:

breeze ui check-translation-completeness --language <locale> --remove-unused

Now translate the TODO: translate: entries following the locale-specific guideline, then continue to Validation below.


Validation

After completing translations, run these checks:

Check completeness. The output table should show 0 missing, 0 TODOs, 0 unused, and 100% coverage:

breeze ui check-translation-completeness --language <locale>

Run pre-commit hooks to fix formatting, licenses, and linting issues:

prek run --from-ref main --hook-stage pre-commit

General Translation Rules

The following rules apply globally. If the locale-specific guideline for a language states differently, follow the locale-specific guideline.

Terms Kept in English

The terms below should remain in English by default. Locale-specific guidelines may override individual entries where an established local convention exists:

TermReason
AirflowProduct name
Dag / DagsAirflow convention; always Dag, never DAG
XCom / XComsAirflow cross-communication mechanism name
Provider / ProvidersAirflow extension package name
REST APIStandard technical term
JSONStandard technical format name
IDUniversal abbreviation
PIDUnix process identifier
UTCTime standard
SchemaDatabase term

Variables and Placeholders

Translation strings use {{variable}} interpolation (i18next format). Never translate or remove variable names inside {{…}}. Placeholders may be reordered as needed for natural word order, but the exact variable casing must be preserved (e.g., {{dagDisplayName}}).

Plural Forms

Airflow uses i18next plural suffixes (_one, _other, and optionally _zero, _two, _few, _many). Provide translations for all plural suffixes that the language requires — the locale-specific guideline specifies which ones. If no locale guideline exists, check the i18next plural rules at https://jsfiddle.net/6bpxsgd4 and provide at minimum _one and _other.

Hotkeys

Hotkey values (e.g., "hotkey": "e") are literal key bindings and should not be translated unless the locale-specific guideline says otherwise.


Translation File Structure

All translation files are JSON files located at:

airflow-core/src/airflow/ui/public/i18n/locales/<locale-name>/

Each locale directory contains namespace JSON files that mirror the English locale (en/). The English locale is the default locale and the primary source for all translations. The current namespace files are:

admin.json, assets.json, browse.json, common.json, components.json, dag.json, dags.json, dashboard.json, hitl.json, tasks.json


Locale-Specific Guidelines

Before translating, read the locale-specific guideline file for the target language. These contain glossaries, tone rules, and formatting conventions tailored to each language. If a locale-specific guideline states differently from a global rule in this document, follow the locale-specific guideline.

Locale CodeLanguageGuideline File
arArabiclocales/ar.md
caCatalanlocales/ca.md
deGermanlocales/de.md
elGreeklocales/el.md
esSpanishlocales/es.md
frFrenchlocales/fr.md
heHebrewlocales/he.md
hiHindilocales/hi.md
huHungarianlocales/hu.md
itItalianlocales/it.md
jaJapaneselocales/ja.md
koKoreanlocales/ko.md
nlDutchlocales/nl.md
plPolishlocales/pl.md
ptPortugueselocales/pt.md
thThailocales/th.md
trTurkishlocales/tr.md
zh-CNSimplified Chineselocales/zh-CN.md
zh-TWTraditional Chineselocales/zh-TW.md

If the target locale file does not yet exist, follow only the global rules in this document.

Skills เพิ่มเติมจาก astronomer

airflow-state-store
astronomer
Persists task and asset state across retries and DAG runs using Airflow 3.3's AIP-103 key/value stores (`task_state_store`, `asset_state_store`) and the…
creating-openlineage-extractors
astronomer
ตัวแยกข้อมูล OpenLineage แบบกำหนดเองสำหรับโอเปอเรเตอร์ Airflow ที่ไม่รองรับและสถานการณ์สายเลือดที่ซับซ้อน สองแนวทาง: เพิ่มเมธอด OpenLineage ลงในโอเปอเรเตอร์ที่คุณเป็นเจ้าของโดยตรง (แนะนำ) หรือสร้างตัวแยกข้อมูลแบบกำหนดเองสำหรับโอเปอเรเตอร์ของบุคคลที่สามที่คุณไม่สามารถแก้ไขได้ ตัวแยกข้อมูลจะสกัดกั้นการทำงานของโอเปอเรเตอร์ที่สามจุด: ก่อนการดำเนินการสำหรับสายเลือดแบบคงที่ หลังจากสำเร็จสำหรับเอาต์พุตที่กำหนดในรันไทม์ และหลังจากล้มเหลวสำหรับสายเลือดบางส่วน ลงทะเบียนตัวแยกข้อมูลผ่าน airflow.cfg หรือสภาพแวดล้อม...
debugging-dags
astronomer
การวิเคราะห์สาเหตุที่แท้จริงอย่างเป็นระบบและการแก้ไขสำหรับ Airflow DAGs ที่ล้มเหลว พร้อมขั้นตอนการตรวจสอบที่มีโครงสร้าง ชี้แนะผ่านกระบวนการวินิจฉัยสี่ขั้นตอน: ระบุความล้มเหลว ดึงรายละเอียดข้อผิดพลาด รวบรวมข้อมูลบริบท และส่งมอบขั้นตอนการแก้ไขที่สามารถดำเนินการได้ จัดหมวดหมู่ความล้มเหลวออกเป็นสี่ประเภท (ข้อมูล โค้ด โครงสร้างพื้นฐาน การพึ่งพา) เพื่อมุ่งเน้นการตรวจสอบและแนะนำการแก้ไขที่เหมาะสม ให้คำสั่ง CLI ที่พร้อมใช้งานสำหรับการดึงข้อมูลบันทึก การเปรียบเทียบการรัน การล้างงาน และ DAG...
delegating-to-otto
astronomer
Drives Astronomer's Otto agent (`astro otto`) as a delegated sub-agent for Airflow, dbt, and data-engineering work. Use when the user explicitly asks to "use…
deploying-airflow
astronomer
ปรับใช้ Airflow DAGs และโปรเจกต์ ใช้เมื่อผู้ใช้ต้องการปรับใช้โค้ด, ส่ง DAGs, ตั้งค่า CI/CD, ปรับใช้สู่ระบบผลิต หรือสอบถามเกี่ยวกับกลยุทธ์การปรับใช้…
deploying-go-sdk-bundles
astronomer
สร้าง, แพ็ก, และปรับใช้ชุดรวม Airflow Go SDK ที่คอมไพล์แล้ว เพื่อให้ ExecutableCoordinator สามารถรันได้ ใช้เมื่อผู้ใช้ต้องการคอมไพล์ชุดรวมงาน Go, ถาม…
testing-dags
astronomer
วงจรการทดสอบ-ดีบัก-แก้ไขแบบวนซ้ำสำหรับ Airflow DAGs พร้อมการวินิจฉัยข้อผิดพลาดอย่างครอบคลุม เริ่มต้นด้วย af runs trigger-wait <dag_id> เพื่อรัน DAG และรอให้เสร็จสมบูรณ์ ไม่จำเป็นต้องตรวจสอบก่อนเริ่มต้น เมื่อเกิดข้อผิดพลาด ให้ใช้ af runs diagnose เพื่อสรุปข้อผิดพลาดอย่างครอบคลุม และ af tasks logs เพื่อตรวจสอบรายละเอียดข้อผิดพลาดจากงานเฉพาะ รองรับการกำหนดค่าเอง การหมดเวลา และการลองใหม่ จัดการสถานการณ์สำเร็จ ล้มเหลว และหมดเวลาพร้อมการตีความผลลัพธ์ที่ชัดเจน มีการตรวจสอบความถูกต้องอย่างรวดเร็ว...
tracing-downstream-lineage
astronomer
ติดตามสายข้อมูลปลายน้ำเพื่อประเมินผลกระทบจากการเปลี่ยนแปลงก่อนปรับแก้ตารางหรือ DAG ระบุผู้บริโภคโดยตรงของตารางเป้าหมายหรือ DAG ผ่านการค้นหาในซอร์สโค้ด การขึ้นต่อกันของวิว และการเชื่อมต่อเครื่องมือ BI สร้างแผนผังการขึ้นต่อกันแบบสมบูรณ์ที่แสดงผลกระทบปลายน้ำทั้งหมด ตั้งแต่ตารางไปจนถึงแดชบอร์ดและโมเดล ML จัดหมวดหมู่การขึ้นต่อกันตามความสำคัญ (วิกฤต สูง ปานกลาง ต่ำ) เพื่อจัดลำดับความสำคัญในการสื่อสารกับผู้มีส่วนได้ส่วนเสียและการทดสอบ สร้างรายงานผลกระทบพร้อมการประเมินความเสี่ยง ผลกระทบที่ได้รับ...