Apache Airflow 土耳其语（tr）UI 翻译规范：术语体系、语音学规则与仓库实现详解

本篇基于 Airflow 仓库中的土耳其语翻译 Agent 技能文档 tr.md，系统讲解土耳其语 locale 的完整术语对照体系、语音学规则与格式约定，并结合 UI 源码、breeze 工具链和 CI 配置说明该规范在仓库中的落地位置与验证方式。读完后，你将掌握为 Airflow UI 生成或维护土耳其语翻译字符串所需的全部标准：哪些术语永不翻译、哪些术语必须使用既定译名、如何正确使用元音和谐与所有格后缀、如何补齐 i18next 复数形式，以及如何用仓库自带工具校验翻译完整度。

一、规范在 Airflow i18n 体系中的位置

Airflow 的 UI 国际化由三层文件协同约束，土耳其语规范文档是其中"语言特定层"的核心：

1. 总策略层：i18n 策略文档 定义了默认 locale（英语 en）、"完整翻译"标准（覆盖默认 locale 至少 90% 词条）、locale 归属人（translation owner）与代码属主（code owner）制度，并明确"locale 特定指南文件与本文档冲突时，以 locale 特定指南优先"。
2. 任务流程层：SKILL.md 是翻译 Agent 技能的总入口，定义了"新增 locale / 更新现有翻译 / 校验"三条工作流、全局术语规则（保留英文的术语、{{...}} 占位符保护、热键不翻译）、10 个命名空间文件的清单，以及各语言指南文件的索引表。
3. 语言特定层：本文的主角 tr.md 专门规定土耳其语的术语表、语调、元音和谐、复数形式、大小写与所有格构造，供 AI 翻译 Agent 产出与既有翻译完全一致的新字符串。

土耳其语 locale 在仓库中的注册点均可直接查证：

• UI 语言配置：config.ts 中 supportedLanguages 数组含 { code: "tr", name: "Türkçe" }；
• PR 自动打标签：boring-cyborg.yml 中 translation:tr 标签匹配 airflow-core/src/airflow/ui/public/i18n/locales/tr/*；
• 评审归属：CODEOWNERS 中 locales/tr/ 指定了专属翻译属主；
• 翻译文件本体：tr/ 目录 下 10 个命名空间 JSON（admin.json、assets.json、browse.json、common.json、components.json、dag.json、dags.json、dashboard.json、hitl.json、tasks.json），与英语默认 locale 一一对应。

二、核心术语：永不翻译 vs 按惯例翻译

tr.md 将 Airflow 术语分为两类，这是土耳其语翻译与部分其他 locale 最显著的区别。

2.1 全局永不翻译的术语

以下术语在所有 Airflow locale 中定义为不可翻译，土耳其语也不例外：

术语	保留理由
Airflow	产品名
Dag / 复数 Dag'ler	Airflow 概念；绝不写作 "DAG"，土耳其语复数用撇号：Dag'ler
JSON	标准技术格式名
ID	通用缩写
PID	Unix 进程标识符
REST API	标准技术术语
Unix	操作系统名
UTC	时间标准
XCom / 复数 XCom'lar	Airflow 交叉通信机制名
日志级别 CRITICAL、ERROR、WARNING、INFO、DEBUG	日志级别关键字

2.2 土耳其语特有的"按惯例翻译"术语

与一些保留英文术语的 locale 不同，现有土耳其语翻译将许多 Airflow 核心概念译为本地词汇，这些既定译名必须一致沿用：

英文	土耳其语
Asset / Assets	Varlık / Varlıklar
Backfill	Geriye Dönük Çalıştırma
Catchup	Yakalama
Plugin / Plugins	Eklenti / Eklentiler
Pool / Pools	Havuz / Havuzlar
Provider / Providers	Sağlayıcı / Sağlayıcılar
Trigger / Triggerer	Tetikleyici（名词/组件名）
Executor	Yürütücü

这些译名在仓库翻译文件中有直接实证，并非文档孤证。以 tr/admin.json 为例：

"executorClass": "Yürütücü Sınıfı",     // Executor → Yürütücü
"triggererJob": "Tetikleyici İşi",       // Triggerer → Tetikleyici
"pool_one": "Havuz",
"pool_other": "Havuzlar"                 // Pool → Havuz（复数加 -lar 后缀）

tr/common.json 中同样可查到 "darkMode": "Karanlık Mod"、"asset_one": "Varlık"、"backfill_one": "Geriye Dönük Çalıştırma" 等条目，与规范文档逐条吻合。

三、标准翻译术语表

tr.md 规定了约 30 个 Airflow 特定术语的既定土耳其语译法，新字符串必须与之保持一致：

英文术语	土耳其语翻译	备注
Task	Görev	复数："Görevler"
Task Instance	Görev Örneği	复数："Görev Örnekleri"
Task Group	Görev Grubu
Dag Run	Dag Çalıştırması	复数："Dag Çalıştırmaları"
Trigger（动词）	Tetiklemek	"Triggered" 译为 "Tetiklendi"
Trigger Rule	Tetikleme Kuralı
Scheduler	Zamanlayıcı
Schedule（名词）	Zamanlama
Operator	Operatör	复数："Operatörler"
Connection	Bağlantı	复数："Bağlantılar"
Variable	Değişken	复数："Değişkenler"
Configuration	Yapılandırma
Audit Log	Denetim Günlüğü
Log	Günlük	复数："Günlükler"
State	Durum
Queue（名词）	Kuyruk	"queued" 译为 "Kuyrukta"
Duration	Süre
Owner	Sahip
Tags	Etiketler
Description	Açıklama
Documentation	Dokümantasyon
Timezone	Saat Dilimi
Dark Mode	Karanlık Mod
Light Mode	Aydınlık Mod
Asset Event	Varlık Etkinliği	复数："Varlık Etkinlikleri"
Dag Processor	Dag İşlemcisi
Try Number	Deneme Sayısı
Heartbeat	Kalp Atışı	如 "Last Heartbeat" → "Son Kalp Atışı"
Upstream / Downstream	Yukarı Akış / Aşağı Akış

值得注意的语义细节：Schedule（名词）译为 Zamanlama，而 Scheduler（组件）译为 Zamanlayıcı——前者是"排程"这一行为，后者是执行排程的组件，这与 Airflow 中"调度器"与"调度策略"的区分对应。

四、Task / Dag Run 状态翻译表

UI 中所有状态徽章的土耳其语映射如下，tr/common.json 的状态块已按此表完整实现：

英文状态	土耳其语翻译
running	Çalışıyor
failed	Başarısız
success	Başarılı
queued	Kuyrukta
scheduled	Planlanmış
skipped	Atlanmış
deferred	Ertelenmiş
removed	Kaldırılmış
restarting	Yeniden Başlatılıyor
up_for_retry	Yeniden Denenecek
up_for_reschedule	Yeniden Zamanlanacak
upstream_failed	Yukarı Akış Başarısız
no_status / none	Durum Yok
planned	Planlanmış

仓库中可交叉验证的典型条目："queued": "Kuyrukta"、"upstream_failed": "Yukarı Akış Başarısız"、"no_status": "Durum Yok"。另注意 tr/dag.json 中的派生复数形式，如 "failedRun_one": "Başarısız Çalıştırma" / "failedRun_other": "Başarısız Çalıştırmalar"，体现了"形容词 + 所有格名词 + 复数后缀"的组合方式（Başarısız 前缀 + Çalıştırma 名词 + -lar 复数后缀）。

五、土耳其语特定语言规则

本节是 tr.md 区别于其他 locale 指南的精华所在——它把土耳其语语法机制直接翻译成翻译工程约束。

5.1 语气与语域（Tone and Register）

• 使用适合技术软件 UI 的中性、正式土耳其语；
• 指示性语句使用礼貌祈使形式（如 "press key" → "tuşuna basın"）；
• UI 字符串必须简洁——它们出现在按钮、标签和提示框中。

5.2 元音和谐与后缀（Vowel Harmony）

土耳其语的后缀元音必须与词根末位元音"和谐"匹配。文档给出两条正例：

• Dag'ler（不是 Dag'lar）——遵循前元音和谐；
• Bağlantılar——遵循后元音和谐。

专有名词和缩写加后缀前必须使用撇号：Dag'ler、XCom'lar。这条规则直接决定了含产品词的所有复数/所有格形式。

5.3 复数形式：只用 _one 与 _other

土耳其语在现有翻译中仅使用 i18next 的 _one 和 _other 两个复数后缀，不存在 _many 或 _zero。规范文档给出的键值对示例：

"task_one": "Görev",
"task_other": "Görevler"

"dagRun_one": "Dag Çalıştırması",
"dagRun_other": "Dag Çalıştırmaları"

这一语言决策在 breeze 工具链中被硬编码：ui_commands.py 的 PLURAL_SUFFIXES 字典中 "tr": MOST_COMMON_PLURAL_SUFFIXES，而该常量定义为 ["_one", "_other"]（同文件 L71）。这意味着：

• 执行 --add-missing 脚手架时，工具只会为 tr 生成 _one/_other 两种键；
• 执行 --remove-unused 时，tr 文件里任何多余复数后缀键都会被识别为未使用并清除。

5.4 大小写规则

• UI 标题、导航项、按钮标签使用标题式大写（每个主要单词首字母大写），如 "Tüm Çalıştırmalar"、"Genel Bakış"；
• 描述性文案和较长消息使用句首大写；
• 复合术语的每个主要词首字母大写："Dag Çalıştırması"、"Görev Örneği"。

5.5 所有格构造（Possessive Constructions）

土耳其语用所有格后缀表达复合名词的领属关系，Airflow 术语组合依赖这一机制：

• Dag Çalıştırması（Dag's run）——所有格 -ı/i 后缀；
• Görev Grubu（Task's group）——所有格 -u/ü 后缀；
• Bağlantı Kimliği（Connection's ID）——所有格 -ı/i 后缀。

这条规则解释了为什么 ID 不翻译但 Kimlik（标识）可翻译：Bağlantı Kimliği 是"Connection 的 ID"这一自然语序的土耳其语化，而缩写 ID 本身仍保留。

六、既有翻译中的典型模式（可直接引用的语料）

6.1 术语本地化对照（与其他 locale 的关键差异）

Asset          → "Varlık"
Backfill       → "Geriye Dönük Çalıştırma"
Pool           → "Havuz"
Plugin         → "Eklenti"
Provider       → "Sağlayıcı"
Executor       → "Yürütücü"
Trigger        → "Tetikleyici"
Heartbeat      → "Kalp Atışı"
Upstream       → "Yukarı Akış"
Downstream     → "Aşağı Akış"

6.2 常见复数与单数键模式

task_one              → "Görev"
task_other            → "Görevler"
dagRun_one            → "Dag Çalıştırması"
dagRun_other          → "Dag Çalıştırmaları"
backfill_one          → "Geriye Dönük Çalıştırma"
backfill_other        → "Geriye Dönük Çalıştırmalar"
taskInstance_one      → "Görev Örneği"
taskInstance_other    → "Görev Örnekleri"
allRuns               → "Tüm Çalıştırmalar"
running               → "Çalışıyor"
failed                → "Başarısız"
success               → "Başarılı"
queued                → "Kuyrukta"
scheduled             → "Planlanmış"

其中 backfill_one/backfill_other 在 tr/common.json 中逐字存在，可作为新键翻译的参照基准。

6.3 Trigger 组件的复合名词（已本地化）

triggerer.class           → "Tetikleyici sınıfı"
triggerer.id              → "Tetikleyici Kimliği"
triggerer.createdAt       → "Tetikleyici oluşturma zamanı"
triggerer.assigned        → "Atanmış tetikleyici"
triggerer.latestHeartbeat → "En son tetikleyici kalp atışı"
triggerer.title           → "Tetikleyici Bilgisi"

上述条目与 tr/common.json 中 triggerer 对象的实际内容一致（class、createdAt、id、title 四项均可逐字查证）。注意这里同时体现了两条规则：Heartbeat → Kalp Atışı（术语表）与 ID 保留 + Kimliği 所有格形式（5.5 节）。

6.4 动作动词（按钮）与健康状态标签

Add      → "Ekle"
Delete   → "Sil"
Edit     → "Düzenle" / "Güncelle"
Save     → "Kaydet"
Reset    → "Sıfırla"
Cancel   → "İptal"
Confirm  → "Onayla"
Import   → "İçe Aktar"
Search   → "Ara"
Filter   → "Filtrele"
Download → "İndir"
Expand   → "Genişlet"
Collapse → "Daralt"

Healthy   → "Sağlıklı"
Unhealthy → "Sağlıksız"

仓库实证：tr/common.json 有 "delete": "Sil"，L154-L161 有 "add": "Ekle"、"cancel": "İptal"、"confirm": "Onayla"、"save": "Kaydet"，L101 有 "download": "İndir"；健康标签 "healthy": "Sağlıklı" / "unhealthy": "Sağlıksız" 位于 tr/dashboard.json 与 L20。

七、翻译 Agent 的 DO / DON'T 清单

tr.md 末尾给出面向 AI 翻译 Agent 的硬性操作清单，可作为评审翻译 PR 时的检查表。

必须做到（DO）：

• 风格、语调、元音和谐、大小写与现有 tr/*.json 文件保持一致；
• 使用适合专业 UI 的正式、中性土耳其语；
• 保留所有 i18next 占位符：{{count}}、{{dagName}}、{{hotkey}} 等；
• 后缀应用正确的土耳其语元音和谐；
• 专有名词和缩写加后缀前使用撇号（Dag'ler、XCom'lar）；
• 为每个复数键提供所需的全部复数后缀（tr 即 _one、_other）；
• 新增翻译前先核对现有翻译以维持一致性。

严禁做到（DON'T）：

• 写作 "DAG"——永远写作 "Dag"；
• 使用非正式或口语化土耳其语；
• 在既有土耳其语翻译已确立本地译名时把术语留在英文（这一点与其他 locale 相反，土耳其语翻译了绝大多数术语）；
• 现有翻译已有对应词时生造新词汇；
• 修改热键值（例如 "hotkey": "e" 必须保持 "e"）；
• 翻译 {{...}} 内部的变量名或占位符。

这些规则与总技能文档 SKILL.md 的全局规则衔接：占位符变量名永不可翻译、热键字面量不翻译；locale 指南与全局规则冲突时，以 locale 指南为准。

八、实操流程：在仓库中落地与维护 tr 翻译

结合 SKILL.md 与 i18n 策略文档 中定义的工具链，土耳其语翻译的完整工作流如下（适用于当前仓库结构）：

1. 了解现状：先读 tr.md 建立术语与格式基线，再通读 tr/ 目录 下 10 个 JSON 文件，凡是已存在的译法一律原样复用。

2. 检查完整度：

   breeze ui check-translation-completeness --language tr
   

3. 补齐缺失键（生成 TODO: translate: 脚手架，占位前缀在翻译时必须一并替换）：

   breeze ui check-translation-completeness --language tr --add-missing
   

4. 清理未使用键（键在英语 locale 中不存在，或属于该语言不需要的复数后缀）：

   breeze ui check-translation-completeness --language tr --remove-unused
   

5. 验证：完整度检查输出应为 0 missing、0 TODO、0 unused、100% 覆盖；随后运行 pre-commit 钩子修复格式、许可证头与 lint 问题：

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

从源码结构看，第 3、4 步的"该语言需要哪些复数后缀"完全由 ui_commands.py 中 PLURAL_SUFFIXES 的 "tr" 条目（["_one", "_other"]）驱动，因此 tr 翻译文件永远不应出现 _zero/_few/_many 键——出现即视为未使用键，会被工具自动清除。

按 i18n 策略，合并翻译 PR 前语言变更须由该 locale 的 translation owner 批准（tr 目录的属主在 CODEOWNERS 中声明），且"完整翻译"需覆盖默认 locale 至少 90% 的词条。

九、适用前提与小结

• 本规范适用于 Airflow core UI 翻译（airflow-core/src/airflow/ui/public/i18n/locales/tr/），tr.md 版本号为 1.0，依据 2026 年 7 月前后的 tr/*.json locale 文件导出；
• 规范文档自称"derived from existing tr/*.json locale files"，即它是从既有翻译中归纳的一致性标准，而非凭空制定的规则——写作新字符串时的第一原则就是与既有语料对齐；
• 土耳其语规范的核心可归纳为四点：Dag/XCom/Airflow 等产品词永不翻译且缩写复数加撇号；Pool、Backfill、Provider、Executor 等概念词必须用既定土耳其语译名；复数只走 _one/_other；后缀元音必须和谐、复合名词用所有格构造。

遵循以上规则并通过 breeze 完整度校验后，新的土耳其语字符串即可与 tr/ 目录 既有翻译保持一致性，满足 i18n 策略 对合并的要求。