邮件本地化：如何在各大主流 ESP 中翻译营销邮件

我负责生命周期营销，所以大半时间都耗在营销活动编辑器里，而邮件本地化是我一直以来最容易低估的一件事。翻译落地页是一项模式固定的工作；但在不同的工具中翻译邮件营销活动，却完全是另一回事，因为每个平台对“语言”到底是什么，都有各自的一套逻辑。

有些平台会自动帮你翻译文案；有些则提供空白的语言区域插槽，等着你手动填充；还有的甚至要求你在邮件正文中手写分支逻辑。而在这些差异之下，潜藏着同一个风险：文案中布满了模板语法，翻译后必须确保这些语法原封不动、分毫不差，否则邮件发送就会报错。

本指南涵盖了各大主流平台的实际操作方式、如何导出和导入文本，以及在任何平台上都通用的操作要点。

邮件平台处理语言的三种方式

在深入了解各平台的细节之前，搞清楚你所面对的是哪种架构非常有帮助。它决定了你的整个工作流程，而且通常是无法更改的。

大多数成熟的多语言项目都集中在中间这一行，这也是本指南着墨最多的部分，因为当“平台为你提供一个空白的语言区域网格”时，正是翻译工作流变得不可或缺的时刻。

Braze 邮件本地化

Braze 采用的是“标签填充”模式，其语法在同类平台中最为独特。你需要使用带有 ID 的 Liquid 标签将邮件中每个可翻译的部分包裹起来：

{% translation greeting %}Hello!{% endtranslation %}

通用格式为 {% translation your_id_here %}默认文本{% endtranslation %}，且单条消息内的 ID 必须唯一。编辑器提供了包裹选定内容的快捷键（macOS 为 Cmd+Alt+L，Windows 为 Ctrl+Alt+L）。Braze 本身不提供翻译功能：你需要通过上传 CSV 文件或使用 翻译 API 来提供翻译，截至本文撰写时，该 API 仍处于抢先体验阶段。

一旦营销活动进入实战阶段，官方文档中列出的这些限制就变得至关重要了：

不支持嵌套翻译标签。语言区域信息源自用户个人资料，可在“设置 → 本地化设置”中配置，既可以使用默认的 language 和 country 属性，也可以使用自定义属性；若两者均有设置，则以自定义属性为准。

在开始之前，有两点关于 Braze 的细节值得留意：

包裹 URL 会导致点击跟踪失效，除非被包裹的部分以 ? 或 & 结尾。Braze 的官方文档中直接给出了变通方案：

<a href="https://{% translation id_1 %}example.com{% endtranslation %}?">Shop Now</a>

切勿使用 Excel 打开翻译 CSV 文件。 Braze 的官方文档也明确建议避开它，因为 Excel 在处理非英文字符时会出现显示问题。这是导致 Braze 本地化流程在不知不觉中损坏的最常见原因，且罪魁祸首是 Excel 而非 Braze：Excel 会尝试推测 CSV 的编码，但往往会猜错。

Braze 的内容块 (Content Blocks) 可以包含自身的翻译，这样你只需对共享页脚进行一次本地化，而不必在每个营销活动中重复操作。引用方式为 {{content_blocks.${your_block}}}；通过 Liquid 插入的内容块会保持关联并自动更新，而通过编辑器下拉菜单添加的内容块则不会。如果某个内容块缺少特定语言区域的翻译，它将以原始语言显示，而不会导致渲染失败。

如果你更倾向于使用分支逻辑而非标签，Braze 也支持这种 DIY 方案：

{% if ${language} == 'en' %}
English content
{% elsif ${language} == 'es' %}
Spanish content
{% else %}
Fallback content
{% endif %}

请注意，在 Liquid 标签内部，属性名直接使用 ${language}，而在正文内容中，则需要包裹为 {{${language}}}。Braze 建议始终包含 {% else %} 分支，因为部分用户可能未设置语言、使用了不支持的语言，或者设备语言无法检测。

文档：Braze 本地化

Customer.io 邮件本地化

Customer.io 采用了截然不同的做法：本地化功能是原生的，直接集成在消息编辑器中，并提供了一个 AI 自动翻译按钮。你可以先用默认语言撰写消息，然后直接添加语言变体，而无需拆分营销活动分支。该功能适用于邮件、短信、WhatsApp、推送通知和应用内消息。

语言属性的名称由你自定义。在“工作区设置 → 语言设置”中，你可以指定 Customer.io 读取哪个个人资料属性来获取语言信息，它可以是 language、locale 或 CRM 中现有的任何属性。属性值必须是两位字母代码（如 en），或者是用连字符分隔的语言-地区对（如 en-US）。属性值不区分大小写，因此 es-MX 和 es-mx 均有效，但必须包含连字符。

自动翻译涵盖了正文、主题行和预览文本。而以下这些它无法覆盖的内容，才真正值得你“贴在墙上”重点关注：

• 图片（尽管它会翻译替代文本）
• 富文本和代码编辑器中的邮件布局
• Liquid 静态文本、属性值以及过滤器值
• Snippets
• 自定义组件中的文本，除非你先将组件分离

第三点最容易让人防不胜防，值得举例说明。Customer.io 官方的本地化文档中就使用了这样一行代码：

Bonjour {{ customer.first_name | default:"ami" }}

ami 这个词是为没有记录名字的用户准备的备选文本。它是真实的、面向读者的文案，而且位于 Liquid 过滤器中，自动翻译功能不会处理它。如果你把它发给德国受众，一部分收件人就会收到“ami”这种问候。每个 d``efault: 过滤器中的备选字符串都必须手动为每个语言变体进行翻译，而且界面上不会有任何提示。

还有两个限制需要提前规划：当你修改默认模板时，翻译不会自动更新；此外，带有翻译的 A/B 测试仅适用于单次发送，不支持 API 触发的广播或自动化工作流。

Snippets 值得单独说明。它们是可重用内容的实现机制（{{snippets.your_snippet}}，默认每个大小为 16 KB），自动翻译会跳过它们。Customer.io 的建议是将条件判断语句直接写在 Snippet 内部：

{% if customer.language == 'fr' %}
  Se désabonner
{% elsif customer.language == 'de' %}
  Abmelden
{% else %}
  Unsubscribe
{% endif %}

因此，Customer.io 的方案通常最终表现为：消息正文使用原生变体，而每个共享的 Snippet 内部则使用手动维护的条件语句。在认定 AI 按钮能搞定一切之前，这一点非常值得了解。

文档：Customer.io 本地化

Klaviyo 邮件本地化

Klaviyo 的功能名为 Smart Translations，它可以在营销活动（campaign）或流程（flow）编辑器中将消息内容机器翻译成 60 多种语言。你可以在“设置”→“账户”→“翻译”中通过“翻译消息”开关启用该功能。此功能需要付费账户，免费试用版不提供。

Klaviyo 官方文档中列出的自动翻译范围仅限：文本块、标签和替代文本 (alt text)。主题行并不在其中，因此在认定营销活动已完全覆盖翻译之前，请先在你的账户中进行确认。

语言解析默认使用个人资料中的 Locale（区域设置），如果缺失，则会退而使用 Country（国家）或 Language（语言）。Klaviyo 接受 BCP-47 代码（en-GB、es-ES），也支持 English 或 French 等纯文本值。

Klaviyo 有两个优点让使用体验非常愉快。首先是 “不翻译”列表 (Do Not Translate list)：你可以在账户层级统一指定品牌名称、产品名称以及任何不希望模型处理的术语。大多数平台都没有类似功能，而这正是决定你的产品名称在十个语种中保持一致，还是变成十个不同词汇的关键。

其次是针对单个元素的覆盖菜单。对于任何已翻译的元素，你都可以选择重新翻译 (Re-translate)、匹配源文 (Match source)、编辑 (Edit) 和忽略 (Ignore)，并且可以通过编辑器顶部的箭头在不同语言之间切换。这让审核工作变成了对标记项目的检查，而无需通篇重读。

Klaviyo 还支持 CSV 导入导出流程，如果你有翻译人员或使用外部工具，这正是你需要的。在“翻译” (Translate) → 操作菜单下，有导出 CSV (Export CSV) 选项，支持 Smartling 或 Simple 格式。CSV 的列包括 block_id（每个待翻译字符串的唯一标识符）、source（原始文本），以及按语言代码命名的各语言列。规则严谨且合理：不要编辑或删除 block_id 的值，不要增加行，也不要修改 source 的值。

令从 Braze 或 Customer.io 迁移而来的用户感到意外的是：**Klaviyo 并不使用 Liquid。**它采用的是 Django 模板语法。

{% if person|lookup:'Loyalty Points' > 150 %}
Hey VIP! You've always got free shipping & free returns
{% elif person|lookup:'Loyalty Points' > 0 %}
You have {{ person|lookup:'Loyalty Points' }} points, and you just need 150 to become a VIP!
{% else %}
Have you heard about our VIP program? Join today on our website to start earning rewards.
{% endif %}

这里的标签看起来和 Liquid 非常像，足以以假乱真，但随后 elif 和 elsif 的细微差别就能让你头疼一下午。带有备选文本的个性化变量写法为 {{ first_name|default:'friend' }}。

文档：Klaviyo Smart Translations · Django 语法

Mailchimp 邮件本地化

Mailchimp 并不提供原生的多语言营销活动（campaign）功能。它采用的是条件合并标签（conditional merge tags），官方文档推荐的做法是将所有语言的内容都写在同一封邮件中，由条件语句决定显示哪种语言。

*|IF:MC_LANGUAGE=es|*
Spanish content here.
*|ELSEIF:MC_LANGUAGE=de|*
German content here.
*|ELSE:|*
Display English content for everyone else.
*|END:IF|*

*|MC_LANGUAGE|* 存储联系人的语言代码，*|MC_LANGUAGE_LABEL|* 则存储易读的语言名称。Mailchimp 会尝试根据订阅者的浏览器自动检测语言；你也可以在“个人资料” (profile) → “设置” (Settings) → “语言” (Language) 下为单个联系人手动设置，或在导入时进行批量设置。另外请注意，*|END:IF|* 标签同时用于结束 IF 和 IFNOT 代码块。

通常正是这一个限制决定了最终的方案。如果一封本地化邮件的主题行语言不对，用户根本不会点开邮件，正文写得再好也没用。因此，大多数在 Mailchimp 上处理两种以上语言的团队，最终往往还是会为每种语言单独创建营销活动，而到了这一步，条件合并标签的方法也就毫无益处了。与其在建好模板后才发现，不如在规划阶段就弄清楚这一点。

文档：Mailchimp 内容翻译

Iterable 邮件本地化

Iterable 拥有专门的区域设置（locales）功能，其官方文档对于该功能的实际意义及其局限性描述得直白得令人耳目一新：

区域设置（Locales）并不翻译内容。

它为你提供变体框架，而翻译内容则由你自行提供。作为回报，所有变体都共享同一个 templateId，这样你的数据指标就能保持统一，而不会分散在十个独立的模板中。对于任何尝试过对拆分为多个语言版本的营销活动进行数据报表分析的人来说，仅凭这一点就值得去配置它。

该字段必须准确地命名为 locale。Iterable 明确指出，如果你将其命名为 languagePreference 或其他任何名称，系统将无法把用户与变体进行匹配。区域设置名称遵循 ISO-639 加 ISO-3166 标准（如 fr-CA、fr-FR），同时也支持三位字母代码。区域设置一旦创建****便无法重命名，因此在创建几十个区域设置之前，请先确定好命名规范。如果区域设置留空，则使用默认本地化版本；如果匹配失败，则由项目层级的设置决定是跳过发送还是发送默认版本。

Iterable 也明确不建议采用“自行实现”的方式：

虽然 Iterable 是一个灵活的平台，你或许能够使用 Handlebars 或 Catalog 来创建多语言内容，但这并非本地化的最佳实践。

模板引擎使用的是 Handlebars，且字段名称区分大小写。在所见即所得 (WYSIWYG) 编辑器中有一个坑需要注意：条件语句必须包裹在 HTML 注释中，否则编辑器会将其破坏。

<!--{{#if activeUser}}-->
    <div>Hi active user!</div>
<!--{{else}}-->
    <div>Hi inactive user</div>
<!--{{/if}}-->

至于导入导出流程，可以通过 GET /api/templates/email/get 接口提取模板内容供翻译人员使用。

文档：Iterable 多语言

Brevo 邮件本地化

Brevo 属于那种能为你提供翻译功能的平台，在这项特定功能上，它是 Mailchimp 最直接的竞争对手。你只需创建一个能根据联系人的语言或国家代码自动调整的营销活动，点击 Add languages（添加语言），Brevo 就会为每种语言生成一个副本，供你手动翻译或使用其 AI 助手 Aura 进行翻译。

针对不同语言，你可以调整的内容比大多数平台都要丰富：包括发件人姓名、主题行、预览文本、邮件设计本身，以及回复地址、Google Analytics 追踪和自定义退订页面。其中主题行尤其值得关注，因为这正是 Mailchimp 无法实现的功能。

官方文档中列出的限制如下：不支持基于文件的翻译（这意味着无法进行 CSV 导入导出，如果你需要与外部翻译供应商对接，Brevo 基本上就可以排除了）；不支持 A/B 测试营销活动；且“已保存区块”（saved sections）需要为每种语言各准备一份。如果联系人的语言属性与已配置的任何语言都不匹配，系统将发送默认版本。

文档：Brevo 多语言营销活动

Liquid、Handlebars 和合并标签：必须完整保留的部分

无论使用哪种平台，实际翻译环节都有一个硬性要求：文案中包含模板语法，其中的每一个字符都必须原封不动地返回。一旦 {% endif %} 被翻译，发送就会报错。

以下是本指南涉及的各平台语法示例：

绝大多数错误都可以归结为以下三种失效模式。

模型翻译了标记。 结果你收到了 {{ prénom }} 或 {% si %}，导致发送失败，或者直接显示出了原始代码。任何真正称手的工具都会在文本传给模型之前对标记进行遮蔽，并在翻译完成后将其还原，从而确保模型绝不会把它们误当作普通单词。

模型移动了标记。 不同语言的语序本就不同，标记的位置理应随之调整。但如果标记被移到了错误的子句中，或者 {% if %} 及其对应的 {% endif %} 先后顺序发生了颠倒，麻烦就来了。位置决定含义；解决方法是核对输出的标记集合是否与输入一致，若不匹配，则重新翻译该文本块。

标记数量发生了变化。 遗漏标记最为危险，因为邮件依然能正常渲染，只是会缺失姓名或逻辑分支。这就是为什么核对数量比肉眼检查更重要。

而应对这三种情况的通用准则是：条件分支是独立的字符串。 这一行包含两个独立的文案片段，如果将整行内容一股脑交给翻译人员或模型，其处理效果远不如将两者拆开并分别提供上下文：

{% if ${loyalty_tier} == 'gold' %}Gold members get an extra 10%.{% else %}Join Gold for an extra 10%.{% endif %}

HTML 邮件与字符串表是两类不同的任务

在这条路上有一个决定全局架构的分岔口，而人们往往走到一半才发现它。

有些邮件内容属于文档：比如 HTML 模板、渲染后的邮件，这类内容具有结构和逻辑流，需要从头到尾阅读。你希望将其作为连贯的文案来翻译，因为标题及其下方的正文是一个整体，翻译人员如果能同时看到两者，会比只看到其中之一做出更明智的判断。

另一类邮件内容则是字符串表：这是一种带键（key）的列表，每一行都是独立的。例如 c``ta_button、subject_line、footer_unsub。这类内容自带的元数据往往比文案本身更重要：比如绝对不能更改的键、上下文备注，以及通常会有的字符限制，因为邮件主题如果太长，在收件箱里会被截断。

Braze CSV、Klaviyo CSV 以及软件领域的所有本地化文件格式（如 gettext PO、XLIFF）都属于字符串表。而 HTML 模板则属于文档。如果把字符串表当成文档处理，你会丢失那些键；如果把文档当成字符串表处理，你则会把连贯的文案撕碎成零散的碎片。

这就是为什么我们在 Transept 中将字符串文件支持作为一条独立的路径来构建，而不是将其并入文档导入功能。邮件文案 CSV 文件导入后会以表格形式呈现，包含键、原文和译文，字符限制显示为实时计数器，且每一行都附有上下文备注。

关键的一点是，文件导出时会保持其导入时的原始结构。你导出的是翻译后的原始文件，其中的键和列都位于平台要求的正确位置，而无需在导出后再手动调整格式。

为 Transept 构建邮件支持功能的心得与发现

我们上线字符串文件导入功能正是为了应对这种工作流。在此过程中，我们发现了一些从未见于任何文字记载的情况。这些都是我们通过编写代码和运行测试得出的第一手发现。

从技术层面来看，“50% off” 也是一种 printf 转换

软件字符串常使用 printf 占位符，如 %s、%d、%1$s。如果你在翻译前屏蔽这些占位符，常规的正则表达式通常会兼容 printf 的全套标志，其中就包括 空格标志（% d 会在正数前打印一个空格）。这在 printf 语法中是合法的，支持这种写法也完全站得住脚。

但对于营销文案来说，这简直是一场灾难。如果允许空格标志，50% off 中就会出现一个匹配项：% o 会被解析为带空格标志的八进制转换。100%`` organic 也是如此。还有 Up ``to 70% off，这是促销邮件中最常见的句式。

我们对两种情况都进行了测试：

屏蔽 % o 会导致折扣文案被误当作占位符，传给模型的句子也因此变得支离破碎。我们特意不支持空格标志，这并无大碍：现实中根本没有字符串表会用到它。

Braze 的个性化标签有三个右大括号

这是我们在编写本指南的过程中发现的，这也充分说明了编写指南的必要性。

Braze 的语法是 {{${first_name}}}。数一下右大括号：属性本身带一个 }，再加上闭合 Liquid 输出标签的两个。连续三个。

几乎所有的 Liquid 分词器都会采用非贪婪模式扫描到第一个 }}。面对 {{${first_name}}}，它会提前一个大括号结束：捕获了 {{${first_name}}，留下一个孤零零的 } 混在待翻译文本中。标记看起来已经处理过了，但多出来的那个大括号被当作普通文本传给模型，回来时可能位置变了、重复了，或者干脆消失了。

{{${first_name}}}, your spring sale starts now

  non-greedy scan  →  token: {{${first_name}}     leftover: "}, your spring sale starts now"
  brace-aware scan →  token: {{${first_name}}}    leftover: ", your spring sale starts now"

我们的工具最初也是如此。我们发现并修复了这一问题，使其支持标记内部的一层嵌套，并将 Braze 的具体语法添加到了测试套件中。如果你在维护自己的邮件工具，请务必针对 {{${attribute}}} 进行专门测试，因为普通的 {{ attribute }} 形式运行正常，会让你完全察觉不到这个 bug 的存在。

占位符内的引号会导致 JSON 响应解析失败

当你向模型批量发送字符串并要求以 JSON 格式返回时，响应字符串中若包含未转义的 "，会导致字符串提前闭合，从而使该批次的后续内容全部丢失。我们在处理带有引号属性的占位符时遇到了这个问题，并且在某个模型的测试中，大约 58% 的运行都复现了这一故障。

解决方法并不是在提示词中优化转义指令，而是让传输格式完全不含引号，从而从根本上杜绝故障：模型只会看到不带引号的占位符，之后再恢复其带引号的标准形式。通过提示词要求模型不要破坏 JSON 格式虽然在大多数情况下有效，但这恰恰是最糟糕的可靠性表现，因为你根本察觉不到故障何时发生。

模糊条目仅是信号，而非最终译文

如果你的字符串源自 gettext PO 文件，其中的条目会带有一个 fuzzy 标志，意为“此条目为自动匹配，尚未经过人工确认”。若将模糊条目直接视作最终译文，就等同于将一堆猜测当作已审核的成果导入。

我们在数据填充时会排除这些条目，转而重新翻译，并在输出时去掉 fuzzy 标志。因为届时条目已经过审核，该标志已不再适用。

邮件营销本地化最佳实践

这些习惯决定了项目是进展顺遂还是举步维艰，大致按其能为你省去麻烦的程度排序。

在用户画像层面一次性确定语言区域代码 (Locale Code)。 无论采用两位字母代码还是带地区限定的代码，都要保持全局一致。大多数“译文未显示”的事故，都是因为 nl-BE 的用户画像匹配到了 nl 的邮件内容。

在分发翻译任务前，为每个字符串编写背景信息。 翻译人员在电子表格中看到 Shop the sale 时，根本不知道它是按钮、标题还是链接，也不知道它必须限制在 18 个字符以内。所有提供背景或描述字段的平台，其实都在向你索要最能提升翻译质量的信息，但几乎没人去填。

将字符限制视为首要约束条件。 德语的长度大约是英语的 1.5 到 2 倍。在英语中正合适的行动号召 (CTA) 按钮，换成德语可能就会溢出；原本合适的邮件主题，在收件箱里可能会从单词中间被截断。请务必将字数限制随字符串一并告知，以便翻译人员在翻译时能看到字符计数。

维护一份“不翻译”清单。 包括产品名称、品牌术语和功能名称。Klaviyo 已内置此功能；在其他平台上，这些内容通常保存在术语表中。无论如何，请在首次运行前就制定好清单，而不是等发现产品名出现了六种不同的译法后才去补救。

翻译后备内容。 每一个 default: 过滤器、每一个 {% else %} 分支，以及在姓名缺失时显示的“你好”。这些字符串从不出现在预览中，因此往往会被审核环节遗漏，最终却发送给了那些你最不了解的收件人。

跨邮件复用翻译决策。 营销邮件的文案经常重复：相同的页脚、相同的退订声明、每年同样的季节性话术。翻译记忆库意味着你只需确定一次“选购促销商品”的译法，之后的所有邮件都会沿用，而不会因为三次不同的翻译任务产生了三种不同的说法。

正式发送前，务必对每种语言进行测试。 针对每个语言区域，使用真实的用户画像来渲染实际模板。有些条件语句在编辑器中看似正常，实则只有在渲染后才会暴露问题；这一步能让你在无需付出任何代价的情况下，及时揪出未翻译的后备内容或损坏的逻辑分支。

常见问题解答

什么是邮件本地化？

邮件本地化是将邮件营销活动适配于另一种语言和市场的过程，涉及文案、邮件主题、预览文本、个性化后备内容，以及目标语言区域的格式规范。它与纯翻译的不同之处在于，邮件中包含必须原封不动保留的模板语法（如合并标签、Liquid 或 Handlebars 条件语句），且翻译还必须遵循邮件主题长度等约束条件。

哪些邮件平台支持自动翻译营销活动？

Klaviyo（Smart Translations，支持 60 多种语言）、Customer.io（支持邮件、短信、WhatsApp、推送和应用内消息的 AI 自动翻译）以及 Brevo（通过其 Aura 助手）均可在编辑器内直接生成译文。Braze 和 Iterable 虽然提供了语言区域架构，但仍需用户自行提供译文。Mailchimp 则没有原生的多语言营销功能，主要依靠条件合并标签来实现。

我可以翻译 Mailchimp 的邮件主题吗？

不可以。Mailchimp 的文档指出，翻译邮件主题是无法实现的，因为条件合并标签在主题字段中无法运行。若要通过 Mailchimp 发送本地化主题，你需要为每种语言单独创建一个营销活动，并根据联系人的语言字段进行受众细分。

如何防止翻译损坏我的 Liquid 标签？

在文本进入翻译模型前，先屏蔽其中的令牌，以免模型将其误当作普通单词；待翻译完成后再行还原。在采纳译文前，务必核对输出与输入中的令牌集是否一致。此外，将每个条件分支作为独立的字符串来翻译，而不是将整个 {% if %}...{% endif %} 语句块一股脑地塞给模型，这也能提升翻译质量，因为每个分支都能作为其原本的独立句子来处理。

HTML 邮件和字符串表有什么区别？

HTML 邮件是一种文档：它是具有结构的连贯文本，最好作为一个整体进行翻译，从而确保标题与正文之间的上下文衔接。字符串表则是一个键值对列表，每一行都相互独立，包含一个不可更改的键（Key）、通常还附有上下文说明，且往往有字符限制。Braze 和 Klaviyo 的 CSV 导出文件、gettext PO 文件以及 XLIFF 均属于字符串表。这两者需要采用不同的处理方式：如果将字符串表视作文档，会丢失其中的键；而如果将文档视作字符串表，则会割裂正文，破坏其连贯性。

我应该使用 CSV 导出还是平台的 API 进行翻译？

当翻译是由人工或外部供应商完成时，CSV 导出是更务实的选择，这也是 Braze 和 Klaviyo 官方文档中介绍的方法。而当翻译流程需要定期重复，或者翻译量大到手动处理文件已成为瓶颈时，采用 API 交互流程则更为高效。Braze 提供了一个翻译 API（截至本文撰写时仍处于早期访问阶段），Iterable 则允许通过 GET /api/templates/email/get 接口获取模板内容。Brevo 对这两者均不支持：它没有基于文件的翻译功能，因此营销活动必须在操作界面中进行翻译。

一个邮件营销活动可以支持多少种语言？

这取决于所使用的平台。Braze 每个工作区支持多达 200 个语言区域，且每条消息支持 200 个翻译标签。Klaviyo 通过 Smart Translations 支持 60 多种语言。Customer.io 则支持数百个语言及语言-地区代码。在实际操作中，限制因素往往不在于平台的上限，而在于当源文案变动时，你能确保多少种语言的译文得到及时的审核并保持同步。