柠檬水的颠覆性方法仍在继续本土化

一个革命性的保险政策，让每个人都满意

柠檬水于2016年进入保险市场。这是一个巨大的行业，经过多年的发展，已经成熟，有成熟的市场巨头，但也存在利益冲突、被保险人与保险公司之间缺乏信任等根本性问题。

莱蒙德说:“一旦你知道事情是怎么做的，你就不会不知道你已经知道的事情。”因此，他们没有建立另一家保险公司，遵循行业现状，而是试图专注于解决行业不信任的核心问题。他们集思广益如何改变这种状况，并运用行为经济学和统计学来扰乱市场。

这是一条漫长而充满挑战的道路，但柠檬水正在蓬勃发展。现在，它是一家支持人工智能的全栈保险公司，拥有众多产品，并重新定义了保险业务模式，以消除固有的利益冲突并解决信任问题。

为了消除保险公司拒绝支付客户理赔的印象，Lemonade收取固定费用，并且不从超额收益中获益，超额收益将被分配给社区在年度Giveback中选择的非营利组织。

在美国成功推出后，Lemonade开始向其他市场扩张，并很快意识到他们可以通过本地化显著加速增长。这主要有两个诱因。

挑战1:维护一个精简且无错误的流程

根据Dor的说法，Lemonade之前的翻译管理系统(TMS)是以一种没有版本控制系统的方式建立的。所有的键和翻译都由多个开发人员存储和编辑在一个共享的环境中，这使得他们很难跟踪和选择自己的更改以进行进一步的测试。

“当我们开始时，我们有一个不同的翻译系统，足以满足柠檬水当时的需求。我们在这方面遇到了很多问题。”

开发者在自己的分支/版本中开发自己的功能是很常见的。Lemonade的目标是将相同的方法应用于本地化，让开发者负责测试他们自己对本地化功能的更改。由于所有的键和文本更改都进入了一个共享的翻译版本池，技术团队寻找一种清晰的方法来跟踪不同团队所做的更改，并使测试更容易。

“主要问题是，我们有许多开发者在同一时间基于相同的真实来源致力于翻译功能，这意味着他们必须挑选与功能相关的更改来测试他们自己的更改。这根本无法扩展。”金龟子回忆说。

另一个目标是保护代码并确保它尽可能保持干净。开发过程中可能存在无法投入生产的本地化功能版本。

“我们还希望保持代码整洁，避免在应用程序中未使用的冗余键。它们仍然可以存储在Lokalise项目分支中，但不能存储在我们的代码中。”

挑战2:处理文本的瓶颈

Lemonade很快意识到他们想要更快地标记这些本地化问题。每个开发人员都可以访问自己的登台环境，在那里他们可以测试功能和本地化。使用以前的TMS和本地化方法来查看更改，需要大约2.5分钟的部署周期。这似乎不是一个大问题，但如果将其乘以每天发布/更改的数量，并将其乘以开发人员的数量，您就会很快意识到为什么处理文本会成为Lemonade高速实现流程中的最大瓶颈。

例如，当讲德语的内容创建者和QA团队成员要求更改特定功能时，团队必须:

• 在TMS中实现更改
• 修改特性的值
• 把他们拉到代码处
• 提交到Git
• 在实现每个更改之前，等待2.5分钟的部署周期
• 测试结果并重复该过程(如果需要进一步更改)

“这是我们在德国的第一个集成系统遇到的另一个问题:处理文本成为我们最大的瓶颈之一。”

本地化步骤与翻译分支

在加快翻译过程的同时，为基于特性的开发改进流程管理是Lemonade面临的一个雄心勃勃的挑战。他们专注于使流程更顺畅，知道他们想要实现什么，但不知道具体如何实现。他们开始集思广益，研究翻译管理系统(TMS)的选择。

“那时，我们知道我们想把事情做得更好，我开始寻找一种不同的经颅磁刺激。虽然我不确定我在寻找什么，但我知道我想在发布之前对登台级别进行更改。当我得知要在洛杉矶开设分支机构时，我立刻意识到这正是我们所需要的。多尔说。

为每个开发人员创建特定的翻译分支意味着他们将能够控制这些特性范围所需的翻译更改。因此，并行翻译将不再相互影响，开发人员随后只需将自己的更改拉到源代码中。

“我们想要采用的新工作流程是，每个代码特性所需的任何翻译更改都将在其翻译分支中发生。因此，由于每个开发人员都有自己的本地化分支和测试分支，所以所有的更改都是孤立的，直到将它们拉入代码中。”

在2020年，项目分支是一个相对较新的Lokalise功能，允许用户管理多个版本的翻译。Lemonade很快意识到它的工作方式与代码库中的分支不同。因此，他们的团队开始研究如何从Lokalise的版本翻译功能中获益，并将其与Lokalise的开发人员功能(包括灵活的API和webhook)结合起来。

这有助于解决这两个挑战;开发人员独立地在不同的分支上工作，拥有干净的源代码，并改善处理文本的周转时间。

完全集成，实现无缝更改

幸运的是，柠檬水公司在洛杉矶找到了理想的解决方案。“我们想要想出一个解决方案，使我们能够实现动态翻译更改。这意味着在每个Lokalise分支上更新的字符串将在测试环境中立即更新，并且能够直接在该分支中测试它们。”

解决方案是在Lemonade端实现一个翻译服务(TS)，它将充当Lokalise的代理，并在API和webhook的帮助下收集每个Lokalise分支中发生的所有更改。这涉及到内部的适当协调，确保开发人员并行开发功能，并统一内容的创建和更新方式。Lokalise API足够灵活，可以让Lemonade收集所做的每一个更改，识别它来自哪个分支，这样我们的服务就可以在各自的本地分支中复制它(省去了部署时间)。

一旦开发人员对更改感到满意，他或她就会运行一个命令，将分支合并到生产中的主分支和Lokalise中的主分支中，并提交新的更改。

关于Lemonade选择继续进行自定义集成，Dor分享了以下内容:

“我想要有不同的翻译包，这样如果一些功能在后期生产中恢复，它们可以立即合并并更新到TS。然后我意识到我不需要保留每个分支的整个翻译包，因为我只需要最新的更改。”我们的代码是事实的来源，即使在生产中恢复了分支之后，我们也不需要在Lokalise和所有分支的代码之间完全对等。这是一个对我们很重要的变化。”