关于pipeline包Import与Merge设计决策的技术问询

我尝试用pipeline包模拟gotext的翻译管理功能，执行步骤如下：

• 读取所有模板并构建pipeline.State.Extracted
• 将现有翻译导入pipeline.State.Translations
• 合并Extracted与Translations到pipeline.State.Messages
• 通过Export刷新现有JSON翻译文件
• 生成catalog.go文件

过程中发现需要修改两处流程：

1. Import阶段跳过输出文件：代码中存在判断，若文件匹配输出文件的命名模式则跳过导入：

// TODO: Should we skip files that match output files?
if fmt.Sprintf(i.outPattern, tag) == file {
    continue
}

2. Merge阶段未合并翻译中的Placeholders：从现有翻译导入的Placeholders没有被合并到最终的Messages中

以下是这两项设计决策的可能原因：

1. Import跳过输出文件的设计逻辑 #

这个设计核心是为了避免循环依赖与重复处理：

• 工具的核心流程是从源模板提取未翻译文本，结合人工维护的已有翻译生成最终输出文件。如果不跳过工具自身生成的输出文件，会导致下一次Import时重新读取这些自动生成的文件：
  • 重复导入已处理过的翻译内容，造成数据冗余
  • 可能触发循环更新问题（比如导出的文件被重新导入，再次导出时重复生成相同内容）
• 代码里的TODO注释也说明这是一个待确认的设计方向，但当前实现的核心意图是明确区分人工维护的原始翻译源文件和工具自动生成的输出文件，确保仅处理人工维护的翻译内容，避免工具自身产出干扰流程。

2. Merge阶段不合并翻译中Placeholders的设计逻辑 #

这个设计是为了保证模板占位符的权威性：

• 翻译系统中，占位符的定义应该完全来源于原始模板（即Extracted中的内容），因为模板是文本最终的展示载体，占位符的格式、数量必须和模板严格匹配才能正常渲染。
• 如果合并翻译文件中的Placeholders，可能引发问题：
  • 翻译文件中可能残留旧版本模板的占位符，和当前模板不匹配，导致渲染出错
  • 人工维护翻译时可能误修改占位符结构，若合并会覆盖模板中的正确定义，破坏展示逻辑
• 因此设计上会优先保留模板提取的占位符，确保最终Messages的占位符与当前模板完全一致，翻译仅负责填充对应文本内容，不修改占位符结构。

内容的提问来源于stack exchange，提问作者Touring Tim