Slack 如何发布语言

Slack 目前支持 11 种语言。在过去一年中，我们规划并实施了四种语言的发布：韩语、意大利语以及我们最近发布的中文（简体）和中文（繁体）。

在 Slack，我们将本地化视为推广产品的关键工作。随着新冠疫情在全球的蔓延，世界各地的人们纷纷转为远程工作，许多人不得不重新考虑优先事项。这为我们带来了一种新的紧迫感，我们迫切需要找到新方法来帮助人们远距离完成工作。在看到世界多个地区的空前增长后，我们决定将重心放在新语言的本地化工作上。通过此举，希望我们的服务能解决大家的燃眉之急。

这可以说是一个重大决策，因为本地化是一项重大工程。它涉及整个公司多个团队的投入和协调，包括工程、客户支持、产品管理、设计、销售、市场营销等。而另一方面，本地化能够推动转型。如果本地化做得好，就意味着我们可以用大家自己的语言来提供服务，让大家可以顺畅自然地工作。从中，展现了我们致力于服务世界各地将 Slack 作为虚拟工作场所的人们。

Slack 的本地化团队是整个公司所有支持语言的翻译中心。我们的工作方向是：既要保留我们现有的语言，又要推出新的语言供客户使用。推出新语言是一项艰巨的工作，但同时也为公司带来了蓬勃生机，因为这意味着我们可以为依赖 Slack 开展业务的全球客户提供更好的支持。通过对这些新语言提供支持，我们希望可以让客户的工作变得更简单、更愉悦且更高效。

我们已经建立了相关团队和流程，能够确保在进入新市场时，凭借最高品质的本地化工作让我们的客户受益。如已故南非领导人纳尔逊·曼德拉 (Nelson Mandela) 所言，以对方所能理解的语言与之交流会打动对方，但以对方自己的语言与之交流则会直击对方的内心，这正是我们所秉持的理念。Slack 一如既往地将客户放在首位，这使我们能够在本地化流程中提供一流的语言质量。

开始针对某个市场启动本地化之前，我们会进行背景研究，目的是更好地了解我们的客户及其需求。这项研究采取多种形式。我们直接与本地客户交流，让客户告诉我们目前的 Slack 好不好用，以及以后怎么可以做得更好。我们与定性研究机构合作，了解某一地区影响工作场所的重要特征，包括技术趋势、相关政策、环境因素等。有时，我们会开展正式的当地用户研究，直接与人们会面并了解他们的工作生活。我们还携手分析机构进行定量研究，这为我们提供了一个窗口，从中了解 Slack 目前和之前在某一地区的使用情况。这样做有助于我们在产品体验中找出客户可能会遇到阻碍或问题的具体位置。

为了确保新语言的顺利发布，我们将重点放在三个方面：项目管理、质量保证和工具优化。为了实现这些战略目标，我们把团队分为三个支柱：项目、质量和系统。

• 项目支柱管理所有传入的请求。对于我们的新语言，此支柱负责指派一个联系人，由这个人引入工作、答疑解惑并跟踪整个公司的端到端时间表。
• 质量支柱负责保持整体的质量标准。我们为语言质量设定的及格分数是 97%，这意味着对内容的所有质量评估得分都必须为 97% 或更高，我们才能认为翻译后的内容符合 Slack 的质量标准。对于新语言，这一支柱负责运行语言质量保证 (LQA) 流程，从内部发言人和外部 Beta 测试合作伙伴那里获取错漏问题 (Bug) 和反馈，还要确保所有关键问题在语言发布时都已经解决。
• 系统支柱专注于打造合适的工具和自动化来支持语言的维护工作，另外还要高效地发布新语言。该支柱负责帮助上传文件、调试所有工具问题并解答国际化方面的问题。

Slack 的本地化团队于 2017 年开始发布语言。从那以后，我们通过六次单独的发布不断推进各项流程。以下是我们在本地化过程中所学到的一些经验，在每次发布语言时，我们都牢记这些经验。

对内部合作伙伴开展语言和流程方面的培训

在启动环节，“项目”支柱为各个跨职能团队介绍他们需要了解的市场概况。这解决了很多潜在的挑战点（例如，日期和时间的格式、复数和所有格变化），同时也为团队提供了相应语言的一些初步知识。随着工作的逐步展开，大家就会对工作内容会越来越熟悉。

在跨职能合作的初期，我们会对团队进行 Bug 流程方面的培训并在服务级别协议 (SLA) 层面设定预期。我们把 Bug 分为三类：语言、功能和无需修复。语言类 Bug 属于本地化范畴，我们很可能会修复这些 Bug，因为它们多数是拼写错误、语法错误或占位符位置错误。然后是一些功能类问题，其中可能包括变量内的错误、句子被截断、字词或句子显示为英文，这些将需要由工程和设计团队进行修复。围绕这些 Bug 类别对相关人员进行培训非常重要，这样当我们以后真正遇到内容显示为英文的 Bug 时，工程师便知道这应该不是翻译遗漏的问题，并可以相应地升级。

我们非常熟悉自己的代码，特别是在比较棘手的领域。当我们启动翻译流程时，会尝试优先处理产品中一般难以本地化的内容。对于那些绝对不能出错的命名空间，当翻译好的字符串返回时，我们会非常谨慎。对于我们的团队来说，表情符号的本地化就属于这样的领域，slash 命令的命名空间也是，这些内容的翻译在不同平台之间必须匹配。首先翻译这些内容意味着我们有更多的时间来确保翻译的质量。

节省时间的秘诀：先实施语言质量保证 (LQA) 流程再开展其他质量工程 (QE) 工作

我们的语言 QA 团队和工程 QA 团队是分开的，因此我们知道如何协调各项 QA 工作。确保我们在 QE 测试周期之前进行了上下文检查，有助于我们更早地发现并修复语言类 Bug，并避免问题重复出现。这样做还能暴露出关键问题。举例来说，如果有翻译遗漏，则可能是因为字符串未正确打包纳入翻译文件。这样一来，能让工程团队清楚地了解问题，顺利实施后续步骤，并且可以避免大量的反复沟通。

要做好产品的本地化，很重要的一点是尽可能多地获取母语人士的反馈。我们在建立所有流程时都秉持客户为重的理念，在内部相关人员和外部 Beta 测试合作伙伴的反馈环中，体现得尤为明显。我们会经过很多道反馈环，为的是在最终发布产品时能够拿出最好的产品。

我们发现，通过让内部团队在项目之初就审批词汇表和翻译风格指南，我们就能更好地确保本地化的质量。通过建立这些联系，Slack 内部设立了一个持续不断且几乎能够即时运作的反馈环，这样便能够在将语言发布给 Beta 测试合作伙伴之前实施改进。

我们使用工作流程构建器与各个内部团队进行合作互动。这些团队的志愿者会加入一个专门的语言反馈频道，比如说，我们为意大利语设立了 #意大利语项目反馈频道。我们在反馈频道中设置了一个提示，指导内部的母语人士逐步完成翻译问题的报告流程。通过此流程，他们可以向我们提供他们的姓名、建议、他们认为应该调整的具体字词或短语，以及有助于我们知道翻译位置的任何上下文或屏幕截图。

通过工作流程构建器获取反馈，使我们能够利用集成到系统中的 Jira 迅速将反馈转变为可以优先处理的 Bug。使用此流程，我们可以清楚地了解整个过程。过去，我们只是简单地要求报告问题的人写下具体问题并提供屏幕截图，但这并不一定使我们能够重现问题，也不一定能找到并修复 Bug。

在 Beta 测试阶段，我们为客户建立了类似的工作流程，让他们可以轻松地通过 Slack Connect 频道提交反馈。我们发现，效仿内部反馈的做法非常有用，并且该过程使我们能够随时听取客户的意见并与客户互动。

尝试不同流程并突出改进机会

对过去的流程进行迭代使我们能够更有效地发布语言。使用工作流程构建器来获取内部反馈是一个尝试，它导致了重大的流程转变，并大幅减少了“质量”支柱的调查工作。最近，我们的“系统”支柱提出了一种构想，即对新语种采取文件发送流程；我们每次都会翻译许多相同的内容，而该流程的目标是使内部的这一重复工作自动化。这样，我们的团队可以花时间来更高效地进行项目管理，解决新语言翻译中的困难领域（例如图片）或专注于处理反馈和 Bug。

我们一直在提高效率与质量之间取得平衡，但是，效率过高可能会导致质量下降。因此我们非常注重优先花时间来打牢基础（例如培训供应商团队和建立词汇表）以及评估工作成果（例如接收反馈）。

将外部合作伙伴视为我们团队的一部分

我们把供应商当作是我们团队的外在延伸。我们会尝试尽可能让他们掌握一些必要的知识，以便能够充分了解我们的优先事项。在发布新语言的工作中，我们首先会与供应商接触，解释我们的时间表、测试方案和总体目标。我们的语言服务提供商 (LSP) 使我们能够有把握地翻译语言发布所需的大批量内容，而且通过迭代，我们还发现他们可以帮助我们修复 Bug，从而提高内部人员的工作效率。

语言只是一方面

语言发布具有很严苛的要求，但同时又令人期待。团队的不同成员会在不同的时期经历高峰期。项目经理可能会在一开始安排项目时间表时就需要投入大量工作，质量策略师可能会在临近发布日期时看到大量涌入的反馈，而系统开发人员则需要全程保持联系。非常重要的一点是，我们需要不定期地与各个团队确认，了解是否需要改变计划优先处理其他工作，以确保每个人都能有效合作。

本地化也不仅仅是语言。为了提供成熟的本地化产品，Slack 所有团队之间需要深入合作。我们的产品团队在评估新功能时必须考虑地区性影响和机遇。我们的工程团队会对本地化 Bug 和性能问题做出响应，并构建可全球扩展的系统。我们的客户体验团队直接与世界各地的客户合作，解决诸多问题并在内部与相关团队分享反馈。这些只是不同部门内各种做法的几个示例。总而言之，我们所有这些共同的努力，都是为了使 Slack 成为世界各地人们可以共同参与的更简单、更愉悦且更高效的工作场所。