airflow-translations

Добавить или обновить переводы для интерфейса 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
Систематический анализ первопричин и устранение неисправностей для упавших DAG-графов Airflow с использованием структурированных рабочих процессов расследования. Проводит через четырехэтапный процесс диагностики: выявление сбоя, извлечение деталей ошибки, сбор контекстной информации и предоставление практических шагов по исправлению. Классифицирует сбои на четыре типа (данные, код, инфраструктура, зависимости) для фокусировки расследования и предложения соответствующих исправлений. Предоставляет готовые к использованию команды 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
Развертывание DAG-файлов и проектов Airflow. Используйте, когда пользователь хочет развернуть код, отправить DAG-файлы, настроить CI/CD, выполнить развертывание в рабочей среде или спрашивает о стратегиях развертывания…
deploying-go-sdk-bundles
astronomer
Собирает, упаковывает и развёртывает скомпилированные пакеты Airflow Go SDK, чтобы ExecutableCoordinator мог их запускать. Используйте, когда пользователь хочет скомпилировать пакет задач Go, спрашивает…
testing-dags
astronomer
Итеративные циклы тестирования, отладки и исправления для DAG-файлов Airflow с комплексной диагностикой сбоев. Начните с af runs trigger-wait <dag_id> для запуска DAG и ожидания завершения; предварительные проверки не требуются. При сбое используйте af runs diagnose для получения сводки по сбоям и af tasks logs для просмотра деталей ошибок из конкретных задач. Поддерживает пользовательскую конфигурацию, тайм-ауты и повторные попытки; обрабатывает сценарии успеха, сбоя и тайм-аута с четкой интерпретацией результатов. Доступна быстрая проверка...
tracing-downstream-lineage
astronomer
Отслеживание нисходящей линии данных для оценки влияния изменений перед модификацией таблиц или DAG. Определяет прямых потребителей целевой таблицы или DAG через поиск исходного кода, зависимости представлений и подключения BI-инструментов. Строит полное дерево зависимостей, отображающее все нисходящие воздействия — от таблиц до дашбордов и ML-моделей. Классифицирует зависимости по критичности (критическая, высокая, средняя, низкая) для приоритизации коммуникации с заинтересованными сторонами и тестирования. Формирует отчет о влиянии с оценкой рисков, затронутыми...