airflow-translations

Añadir o actualizar traducciones para la interfaz de Apache Airflow. Guía a través de la configuración de locales, la creación de archivos de traducción, la traducción con especificidad de configuración regional…

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.

Más skills de 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
Extractores personalizados de OpenLineage para operadores de Airflow no soportados y escenarios complejos de linaje. Dos enfoques: agregar métodos de OpenLineage directamente a los operadores que posees (recomendado), o crear extractores personalizados para operadores de terceros que no puedes modificar. Los extractores interceptan la ejecución del operador en tres puntos: antes de la ejecución para linaje estático, después del éxito para salidas determinadas en tiempo de ejecución, y opcionalmente después del fallo para linaje parcial. Registra los extractores mediante airflow.cfg o variables de entorno...
debugging-dags
astronomer
Análisis sistemático de causa raíz y remediación para DAGs de Airflow fallidos con flujos de trabajo de investigación estructurados. Guía a través de un proceso de diagnóstico de cuatro pasos: identificar la falla, extraer detalles del error, recopilar información contextual y entregar pasos de remediación accionables. Clasifica las fallas en cuatro tipos (datos, código, infraestructura, dependencia) para enfocar la investigación y sugerir correcciones apropiadas. Proporciona comandos CLI listos para usar para recuperación de registros, comparación de ejecuciones, limpieza de tareas y 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
Desplegar DAGs y proyectos de Airflow. Úsalo cuando el usuario quiera desplegar código, enviar DAGs, configurar CI/CD, desplegar a producción, o pregunte sobre estrategias de despliegue…
deploying-go-sdk-bundles
astronomer
Compila, empaqueta e implementa paquetes compilados del SDK de Airflow Go para que ExecutableCoordinator pueda ejecutarlos. Úsalo cuando el usuario quiera compilar un paquete de tareas de Go, solicite…
testing-dags
astronomer
Ciclos iterativos de prueba-depuración-corrección para DAGs de Airflow con diagnóstico completo de fallos. Comience con af runs trigger-wait <dag_id> para ejecutar un DAG y esperar su finalización; no se necesitan comprobaciones previas. En caso de fallo, use af runs diagnose para obtener un resumen completo del fallo y af tasks logs para inspeccionar los detalles del error de tareas específicas. Admite configuración personalizada, tiempos de espera e intentos de reintento; maneja escenarios de éxito, fallo y tiempo de espera con una interpretación clara de la respuesta. Validación rápida disponible...
tracing-downstream-lineage
astronomer
Rastrea el linaje de datos descendente para evaluar el impacto de cambios antes de modificar tablas o DAGs. Identifica los consumidores directos de una tabla o DAG objetivo mediante búsqueda en código fuente, dependencias de vistas y conexiones de herramientas de BI. Construye un árbol de dependencias completo que mapea todos los impactos descendentes, desde tablas hasta paneles y modelos de ML. Clasifica las dependencias por criticidad (crítica, alta, media, baja) para priorizar la comunicación con las partes interesadas y las pruebas. Genera un informe de impacto con evaluación de riesgos, afectados...