Apache Airflow UI 简体中文翻译指南zh-CN 语言区域规范与 i18n 体系实践【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflowApache Airflow 的 Web UI 已支持 18 种以上语言其中简体中文zh-CN的语言区域文件维护着一套专门的翻译规范复数形式如何处理、中英文混排时的空格规则、全角与半角标点的使用边界、量词的选择、敬语语气以及{{变量}}占位符的保留方式。本文以 zh-CN 翻译规范文档 为主体完整继承其中的全部规则与示例并结合 Airflow 核心 UI 的 i18n 源码、Breeze 翻译完整性检查工具 和 zh-CN 语言区域 JSON 文件 展开佐证帮助你理解每条规则背后的工程机制能够独立承担 Airflow UI 简体中文的翻译、补全与校验工作。zh-CN 规范在 Airflow i18n 体系中的位置Airflow UI 的翻译文件按语言区域组织在airflow-core/src/airflow/ui/public/i18n/locales/locale-name/英文en是默认语言区域是所有翻译的唯一来源。每个语言区域目录包含一组命名空间 JSON 文件与英文语言区域一一镜像当前的命名空间文件为admin.json、assets.json、browse.json、common.json、components.json、dag.json、dags.json、dashboard.json、hitl.json、tasks.json简体中文的这 10 个文件位于 airflow-core/src/airflow/ui/public/i18n/locales/zh-CN/。父级技能文档 SKILL.md 定义了所有语言的通用翻译规则和工作流新增语言区域、更新现有翻译、校验而 zh-CN 规范文档是其语言区域特定的补充凡与全局规则不一致之处以语言区域文档为准。从 src/i18n/config.ts 可以看到zh-CN是 UI 运行时注册的受支持语言之一界面中显示为简体中文{ code: zh-CN, name: 简体中文 },此外Airflow 的 i18n 策略文档 i18n/README.md 规定了一个语言区域必须覆盖默认语言区域至少 90% 的词条才被视为完整翻译并且每个非英文语言区域需要至少一名翻译负责人和代码负责人。zh-CN 规范文档就是翻译负责人日常遵循的语言质量准则。复数形式中文不需要区分单复数但文件结构必须对齐英文zh-CN 规范的第一条核心规则简体中文不区分单数和复数_one和_other两个后缀必须使用完全相同的译文。英文源文件dagRun_one: Dag Run, dagRun_other: Dag Runs正确做法——两者译文相同dagRun_one: Dag 执行, dagRun_other: Dag 执行打开 zh-CN/common.json 可以看到这条规则在真实文件中的大规模落地asset_one: 资源与asset_other: 资源、backfill_one: 回填与backfill_other: 回填、dagRun_one: Dag 执行与dagRun_other: Dag 执行成对出现且值完全一致。从源码看为什么中文文件仍然保留_one键在 Breeze 工具 ui_commands.py 中每种语言需要的复数后缀被显式登记zh-CN: [_other],按 i18next 的多数规则中文理论上只需要_other一种形式。但为什么 zh-CN 的 JSON 文件里同时存在_one和_other答案在 expand_plural_keys 函数中翻译完整性检查以英文文件为基准只要英文对某个复数基础键定义了多个形式例如同时存在dagRun_one和dagRun_other或英文值中包含{{count}}就会要求目标语言区域把该基础键的所有复数形式都补齐。因此 zh-CN 文件必须保留_one键——只是它的值与_other相同。这也解释了为何规范文档强调两个后缀使用同一译文这样既满足完整性检查不缺键、无未使用键又符合中文语法。作为对照日语和韩语的语言区域文件如ja/、ko/目录则只保留_other因为它们的英文对应基准中未被扩展出_one要求以外的形式差异——从源码结构看各语言区域_one/_other键的分布差异正是PLURAL_SUFFIXES与expand_plural_keys共同作用的结果。空格规则中英文混排插入半角空格在汉字与相邻的英文单词、数字或符号之间必须插入一个半角空格。正确示例Dag 执行 // 英文与中文之间有空格 最近 12 小时 // 数字两侧有空格 连接 ID // 缩写前有空格 {{count}} 个连接 // 占位符后有空格错误示例Dag执行 // 缺少空格 最近12小时 // 数字两侧缺少空格这条规则在现有 zh-CN 文件中有完整印证。zh-CN/common.json 中dagRun_one: Dag 执行, dagRunId: Dag 执行 ID, dagRunTimeout: Dag 执行超时Dag 执行 ID 同时体现了两条规则英文与中文之间有空格缩写ID之前也有空格。空格规则的价值在于排版可读性——中英混排界面中无空格的Dag执行在视觉上是一个黏连的整体而规范写法让术语边界清晰。标点全角与半角的分界zh-CN 规范将标点使用分为四个明确的边界条件中文句子使用全角标点。英文术语、JSON 或代码内部的内容使用半角标点,.:?中文语境下的括号使用全角包裹英文或变量的括号使用半角()规范文档给出的正反例正确——中文句子用全角confirmation: 确定要删除 {{resourceName}} 吗此操作无法还原。正确——英文/变量语境用半角tooltip: 按下 {{hotkey}} 切换展开判断依据可以概括为一句话句号、问号、感叹号跟着句子的语言归属走括号跟着它包裹的内容类型走。UI 确认弹窗属于中文句子故用全角和。而括号若包裹的是代码、变量或英文标识符则保持半角以免破坏代码片段的视觉连续性。量词数字与名词之间的桥梁中文语法要求数字与名词之间必须有一个量词量词不同语境使用不同量词。zh-CN 规范给出了 Airflow UI 中三个最常用的量词对照表量词使用语境示例个通用对象连接、变量、错误删除 {{count}} 个连接次发生次数执行、运行、尝试最近 {{count}} 次 Dag 执行项列表条目 其他 {{count}} 项翻译时必须注意占位符{{count}}两侧的空格与上文空格规则一致且量词要紧跟在数字占位符之后、名词之前。语气与正式度UI 文案的语气规则使用中性、略带正式的语域在确认对话框和破坏性操作删除、强制重跑等中使用您正式的你例如您即将删除以下连接避免口语化或过于随意的表达保持译文简洁——这些是 UI 标签和按钮文本不是帮助文档。这与 Airflow UI 的实际场景吻合管理页admin 命名空间中大量删除连接、删除变量、清空执行等危险操作确认文案统一使用您开头以提示操作风险。变量与占位符可以调序绝不能翻译翻译字符串使用{{variable}}插值i18next 格式。规范要求保留所有{{variable}}占位符为符合中文自然语序可以调整其位置但绝不能翻译或改动变量名本身。英文源title: Mark {{type}} as {{state}}正确——占位符完整保留、顺序自然化title: 标记 {{type}} 为 {{state}}错误——把变量名翻译成了中文title: 标记 {{类型}} 为 {{状态}}父级文档 SKILL.md 的全局规则进一步强调变量名的大小写必须精确保留例如{{dagDisplayName}}不能写成{{dagdisplayname}}。此外热键值如hotkey: e是字面按键绑定除非语言区域规范另有说明否则一律不翻译——zh-CN 规范没有覆盖这一条因此热键保持原样。术语表以现有 zh-CN 文件为权威词库规范文档的最后一节要求翻译前先阅读现有的 zh-CN JSON 文件以其中已确立的译法作为权威术语表位于airflow-core/src/airflow/ui/public/i18n/locales/zh-CN/。某个词如果已经在别处翻译过必须复用那一译法以保持全局一致如果尚未翻译再参照英文源文件en/并套用本文规则。从 zh-CN/common.json 可以看到这套已确立术语的实际形态admin: { Config: 配置, Connections: 连接, Plugins: 插件, Pools: 资源池, Variables: 变量 }例如Pools固定译为资源池而非池Connections固定为连接。这与父级文档的全局术语表形成互补——以下术语默认保留英文中文语境中也直接引用术语保留原因Airflow产品名Dag/DagsAirflow 约定永远是Dag绝不写作DAGXCom/XComsAirflow 跨任务通信机制名Provider/ProvidersAirflow 扩展包名REST API、JSON、ID、PID、UTC、Schema标准技术术语/通用缩写实际文件中dag_one: Dag直接保留英文正是该规则的执行结果。翻译工作流从脚手架到校验理解了规范之后实际操作流程由 SKILL.md 定义、Breeze 工具支撑如下。第一步检查翻译完整性breeze ui check-translation-completeness --language zh-CN该命令将 zh-CN 目录下的所有 JSON 与英文语言区域逐键对比对比逻辑见 compare_keys报告每个命名空间文件的缺失键missing和未使用键unused并统计TODO: translate:占位条数。第二步补全缺失键 / 清理未使用键如果有缺失键用脚手架模式从英文复制并注入TODO: translate:前缀占位breeze ui check-translation-completeness --language zh-CN --add-missing生成的骨架形如{ allRuns: TODO: translate: All Runs, blockingDeps: { dependency: TODO: translate: Dependency, reason: TODO: translate: Reason } }如果有未使用键——英文语言区域中不存在、或中文不需要的复数后缀——则移除breeze ui check-translation-completeness --language zh-CN --remove-unused--add-missing的实现位于 ui_commands.py它对缺失的每个键值统一写入fTODO: translate: {v}前缀方便翻译者用文本搜索一次性定位全部待办项。第三步翻译 TODO 条目逐条替换TODO: translate: 英文条目连同前缀一起删除全程遵守本文前述的空格、标点、量词、语气与占位符规则并先查 zh-CN 现有文件 对齐既有术语。第四步验证完整性检查的输出表应显示0 missing、0 TODOs、0 unused、100% 覆盖breeze ui check-translation-completeness --language zh-CN然后运行 pre-commit 钩子修正格式、许可证头与 lint 问题prek run --from-ref main --hook-stage pre-commit附新增一个语言区域时的配置点若从英文扩展出全新语言区域zh-CN 已存在此节仅作背景还需同步更新三处配置在 config.ts 的supportedLanguages数组中添加语言条目、在 ui_commands.py 的PLURAL_SUFFIXES字典中登记该语言的复数后缀、以及在 CI 标签配置中登记翻译路径。zh-CN 在这三处均已就位因此日常维护只需执行上述四步工作流。运行时语言检测zh-CN 如何被浏览器选中翻译文件最终如何到达用户浏览器config.ts 中的convertDetectedLanguage函数负责把浏览器的语言标签navigator.languages归一化到受支持代码且该归一化逐条处理每个候选语言以保持优先级顺序。针对中文的特殊映射包括zh-Hans-CN、zh-SG以及裸标签zh都会映射到zh-CN而zh-TW与简中候选并存时按列表顺序优先。config.test.ts 中的测试用例明确验证了这些行为{ expected: zh-CN, languages: [zh-CN, zh, en] }, { expected: zh-CN, languages: [zh-Hans-CN, en] }, { expected: zh-CN, languages: [zh-SG, en] }, { expected: zh-CN, languages: [zh, en] },源码注释还解释了为何要逐条归一化而不是全局降维浏览器语言列表是有序候选i18next 默认只在不存在精确匹配时才把区域码降级为基础码逐条映射才能保证zh-CN这样的区域级代码优先命中而不被折叠成不受支持的zh。要点速查清单完成一段 zh-CN 翻译后按此清单自查复数成对的_one/_other键值完全相同空格汉字与英文单词、数字、缩写ID、占位符{{count}}之间各有一个半角空格标点中文句子全角。包裹代码/变量/英文的括号半角()量词对象用个、次数用次、列表条目用项语气确认与危险操作用您整体中性简洁占位符{{variable}}原样保留、大小写不变可按中文语序调整位置术语Dag不是DAG、XCom、Provider、REST API等保留英文先查 zh-CN 现有 JSON 复用既有译法校验breeze ui check-translation-completeness --language zh-CN显示 0 missing / 0 TODOs / 0 unused再通过 pre-commit 钩子。掌握这套规范后你不仅能翻译单个命名空间文件还能理解 Airflow i18n 体系中英文为源、复数扩展由工具驱动、完整性可机器验证的工程闭环从而安全地参与 Airflow UI 简体中文的长期维护。【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考