翻译软件字符串与邮件模板

与任何文档一样，只需将文件拖入拖放区域或上传对话框中即可。每个字符串都会根据其 ID 作为键名生成独立的区块——在导出时，系统正是依据该键名将每条译文准确放回原来的位置。

• CSV 列通过表头进行识别：key、id 或 Klaviyo 的 block_id；source 或 default（或首个语言列）；目标语言代码或名称；以及附加信息的 context、location 和 character limit。
• 带有地区限定符的语言列会按其书写形式进行识别——es-MX、en-GB、fr-CA、pt_BR 均能准确匹配到对应语言。如果某列看似语言代码但并非 Transept 所支持的代码，系统会在导入时报错而非直接忽略，避免因输入错误而悄然漏掉某个语种。
• 上下文和字符限制列绝非摆设——上下文会作为翻译指引提供给 AI，而字符限制则通过“自动缩短并重试”机制强制执行。

它们被视为已完成的工作，而非待处理的原材料。CSV 中已填充的语言单元格、PO 文件中非空的 msgstr 或 XLIFF 中已填充的 target 都会直接作为该字符串的当前有效译文——无需重新翻译，也不扣除积分。此外，每个导入的语对都会添加到您的 翻译记忆库 中，从而立即为新的翻译提供参考。

有一个特例是经过深思熟虑的：根据 gettext 自身的规则，标记为 fuzzy 的 PO 条目仅属于草稿，因此 Transept 会将其作为未翻译内容导入，而不是把机器推测直接提升为已审核内容。当您完成翻译并导出时，fuzzy 标记将随填充好的 msgstr 一同被清除。

模板令牌——如 {{first_name}} 或 {% if %} 等 Liquid 标签，以及 %s 或 %(count)d 等 printf 转换符——在 AI 看到文本之前都会被屏蔽：模型接收到的是一个不透明标记，无法被翻译，也不会被乱序放置或静默丢弃。在每次回复后，Transept 都会对照源文核对标记数量，并修复或拒绝任何缺失标记的答案。令牌文本本身则会逐字还原。

这种保护同样适用于包含 Liquid 风格令牌或 Mailchimp 合并标签（如 *|FNAME|*）的上传 HTML、文本或 Markdown 文件——从平台粘贴出来的邮件模板在翻译时，所有占位符都会自动完好保留。标签内部的回退文本是唯一的例外，而且是刻意为之：{{ first_name | default:"friend" }} 中的 friend 是所有未登记名字的收件人会看到的内容，因此它会被翻译，而包裹它的标签则不会。

对于本地化内容完全位于标签或条件语句中的模板——如 Braze 翻译标签、Mailchimp 语言区块——系统设有专门的导入路径。请参阅来自 Braze 和 Mailchimp 的邮件模板。

对于字符串文档，编辑器顶栏会新增一个 Strings 按钮。点击即可打开网格视图——每行对应一个字符串，键名、源文和译文并排显示——您可以按键名或文本进行筛选，直接在行内编辑（点击单元格、输入并按 Enter 即可保存），也可以通过每行末尾的箭头离开该视图；当某个字符串需要用到更进阶的功能（如 AI 改写、批注或版本历史记录）时，点击该箭头即可直接跳转到完整编辑器中的对应区块。

文件中设置的字符限制会作为实时计数器显示在每个译文单元格下方，因此字符超长在输入时即可察觉，无需等到导出被拒后才发现。

对于字符串文档，导出菜单中除了常规格式外，还会出现两个选项：

• 原始文件（已翻译）——您上传的 CSV、PO 或 XLIFF 文件，译文已填充至其自身的单元格和条目中。其他所有内容——列顺序、注释、格式，甚至是引号处理上的细节——都与您上传的文件逐字节保持一致，因此文件可以直接导回其来源系统。
• 字符串文件（带键值）——Transept 的 .tstrings.json 格式，在单个文件中包含所有语言的译文，并以字符串 ID 为键。这种格式适用于需要按键名重新导入的流水线和脚本。
• “翻译数据”下的 TMX、XLIFF 和 CSV 选项在处理字符串文档时，其行数据同样以字符串 ID 为键，因此通过 CAT 工具往返处理也能保持标识完整无损。

可以。包含多个语言列的 CSV 文件在导入时会按语言分别生成为一个独立文档并归为一组——各列会直接转换为相应的语言版本，已预先填入的单元格内容也会完整保留。只需针对整组运行一次工作流即可补全未翻译的空白内容，随后一次性导出即可：通过导出“原始文件”，只需单次下载便能自动填满 CSV 文件中的每一个语言列。

如果需要以无界面（headless）方式完成这一流程——通过脚本实现上传、分发多语种、翻译并重新导出——这正是 API 的用武之地。