【ashkeling专稿，未经授权不得转载！】

ashkeling报道/随着游戏市场的全球化，对于任何一款产品而言，想要被不同市场的OB欧宝体育电竞官网接受，都需要对目标市场进行本地化。

但是，本地化并不简单，尤其是对于剧情驱动向的游戏而言，有时候可能需要处理的本地化工作量非常庞大。比如波兰游戏公司CD Projekt Red此前发布的《ob电竞》，其中每一个语言版本都有超过110万文字，考虑到该游戏支持18种语言和11种语言配音，这背后的工作量几乎是难以想象的。

GDC 2023演讲中，来自CDPR的本地化总监Mikolaj Szwed和高级程序员Tommi Nykopp，从本地化管线和技术方面深度讲解了《ob电竞》本地化的技术、工具和方法。

以下是Gamelook听译的完整内容：

Mikolaj Szwed：

首先我们想要展示一些作品：

忘记了先说剧透提示，但我想你们可能听不懂大部分对话内容。我们今天将分享的主题是“赛博朋克2077的本地化：技术、工具和方法”，开始之前，我们先介绍下自己。我是Mikolaj Szwed，在CDPR担任本地化总监，2010年加入公司，参与了此后我们所有的游戏，目前在工作室带领一个15人的内部本地化团队。今天与我一起进行分享的是：

Tommi Nykopp：

我是Tommi Nykopp，在《ob电竞》研发期间，我的职位是高级程序员，如今负责《ob电竞》项目的对话技术话题，此外，我还管理多个剧情话题的编程。

《ob电竞》的本地化管线

Mikolaj Szwed：

我们首先会谈到《ob电竞》项目本地化方面的规模，随后会提及内部本地化团队的组织方式，包括我们是如何工作的。然后，会聊聊我们处理本地化的方式，既包括内部也包括外部供应商的合作。

随后，我会展示一些日常使用的本地化工具，以及一些我们为《ob电竞》研发的、旨在提升本地化质量的支持系统。第二部分，Tommi会分享这些技术和管线是如何做出来的，最后，我们会分享一些成功故事，一些不足，和一些关键的心得，接下来我们正式开始。

你们可能有人看到我们其他同事做的分享，或许知道CPPR主要聚焦于剧情驱动的开放世界3A级RPG游戏，意味着有巨量的内容需要被本地化，既包括游戏内文字，我们称之为屏幕展示，还包括需要配音的对话，我们今天主要讨论的是第二种。

实际上，公司一直在寻求新的、有趣的市场以提供本地化支持。高品质的本地化是我们游戏系列的独特卖点之一，因为，你们可能不知道，CDPR最初成立的时候是一家游戏分销和本地化公司。

所以，我们来谈谈数字，这是我们过去两大项目《ob电竞》和《ob电竞》的简短对比表格：

《ob电竞》总共有18个语言版本，比《ob电竞》多出来的一个语种是泰语，因此这是我们第一次将一款游戏本地化为泰语。这18种语言每一种都有超过110万个单词需要翻译，相当于一本3200页的书籍。

谈到配音，我们有11种配音版本，比《ob电竞》的7种语音版本多了很多，不过，我们后续在次世代版本更新时又给《ob电竞》增加了两个配音版本。而且，每一个配音版本都有超过8.2万个配音文件。所以，到了最后，我们不得不管理将近90万个配音文件，这个量很大。

团队

为了完成这些工作，我们必须打造一个强大的本地化团队才能实现。CDPR的内部本地化团队搭建，实际上从《ob电竞》时期就已经开始了，因此，团队是从《ob电竞》发布之后正式成立的，因为团队希望对本地化流程有更紧密的控制，并确保带来最高的本地化品质。

不过，在介绍本地化团队之前，我希望先说说我们公司里的本地化流程是怎样的，因为，实际上它和大部分其他公司的流程都是不同的。

实际上，我们一开始所有的内容都是用波兰语写的，意味着我们的本地化多了一步，就是要先将波兰语改编为英语，我们有一个专门的内部英语团队来做这件事。随后，英语版本作为其他语言本地化的基础，因为你可以想象到，波兰语到泰语、波兰语到中文、波兰语到韩语，这样的人才比较难找，所以我们将英文版作为所有其他语言本地化的基础。

当然，我们也有VO录音环节，最后会有本地化QA，这是所有本地化项目都比较标准的步骤。重要的是，叙事是我们游戏的关键卖点，这就意味着在整个制作过程中，会有大量的迭代和最后环节的改变和调整，还意味着，所有这些本地化流程彼此之间都是重叠的。因此，我们需要创造管线和工具管理这些改变，让我们内部LPM（本地化项目经理）和外部供应商都能够流畅工作。

CDPR的本地化团队，实际上包含三个二级团队，但我们都在一起工作，而且，尽管我们每个小团队都有不同的任务和职责，但我们认为我们仍然是一个团队。第一部分是英语改编团队，他们的任务是从波兰语改编为英语，这些都是内部完成的。

第二部分的团队是本地化项目经理，他们负责协调本地化到其他语言的过程，但重要的是，这不仅是一份项目经理工作，他们的工作还包括在他们支持的语言上进行创意和艺术控制。

另外，我们还有内部本地化QA团队，这是一个小团队支持我们的日常工作，既包括英语改编，也支持LPM团队。不过，他们实际上最重要的职责就是在本地化QA阶段与外部供应商的协同工作。内部团队与外部供应商的合作，也是CDPR本地化流程的不同之处。

不过，在谈到供应商之前，我们先来说说CDPR内部（本地化）团队。

重要的是，我们的本地化团队是广泛意义上剧情团队的一部分，我们与其他剧情团队合作，也就是故事团队、任务团队和电影场景设计团队，还要与开放世界团队以及音频团队合作，不过，在必要的时候还会与UI以及玩法团队协调。当我们与他们合作的时候，我们试图共同研发工具和管线，这样，他们创作的内容很容易抽取、然后易于做本地化。

此外，本地化团队还参与到我们游戏的世界构建语言设计之中，比如《ob电竞》游戏里，我们有那些区域性不列颠口音，在《ob电竞》当中，我们也参与到了夜之城多语言场景的打造。在游戏里，有些人只用自己的母语或者最多用双语说话，这是很重要的，因为本地化从很早期的时候就参与到了项目制作中。

我们采取了双向路（two-way road）方法，我们与故事团队紧密合作，以便在做文本的时候为他们提供反馈，在真正录音之前帮他们找到不匹配和错误的地方。因为，后续解决这些bug需要的时间更长，代价也更高。

最重要的是，我们对场景描述（scene direction）也负有共同责任，电影场景设计团队帮助设计场景，他们做动态捕捉、部署动画，但负责录制和执导配音的是我们本地化团队。所以我们必须始终保持同步并紧密合作，以便对进度达成一致，确保最终结果是连贯而且是最高质量的。

不过，与CDPR内部团队合作只是我们工作的一部分，另一部分是与外部供应商合作。这里也有一些要点，或许让我们与其他公司与众不同，大体上，这就是我们的方法。实际上，我们大部分时间更倾向于和单语言供应商合作，即便是和更大的公司合作，我们也希望联系本地团队，因为，直接与团队成员联系对我们而言非常重要。

之前提到，我们的LPM还有创意输入，所以我们与翻译人员、编辑、艺术总监直接联系，因为我们需要塑造风格、术语，我们在录制之前对文本进行校阅。

我们相信，为合作伙伴提供充足的元数据和辅助材料以及上下文环境，是实现高品质本地化的关键。因为我们知道，很多的供应商都难以从他们的客户那里获得更多的输入，而我们则试图给他们尽可能多的信息，我们相信，这会在最后带来更高的质量和更好的产品。

最后一点非常简单，但我知道我们很多的供应商都在这方面遇到了困难。我们还有一个问答表格，我知道听起来令人震惊。不过，基本而言，我们与供应商有一个开放电话线路，他们可以始终向我们提问，《ob电竞》的问答超过4000条，这是非常多的。

当他们使用我们的素材时，很正常的是，并非一切都很清晰，我们属于同一个团队的一部分，我们想要实现最高的质量，因此有这样的问答是我们合作的关键。这还可以让人们更加投入，这也可以成为一次本地化QA，因为我们的供应商也会向我们指出错误、矛盾，因为，越多的人盯着一件事，就越容易发现更多其他人不容易发现的错误。

工具

开始之前，需要强调的是，这既包括我们日常用的工具，也包括帮我们进行本地化而打造的辅助系统。因此，我们先来看看剧情内容结构是怎样的：

我们的游戏剧情内容被分为很多的任务，每个任务都包含一些场景，每个场景都包括不同部分，每个部分都包含一行或者多行对话。那么，这在游戏编辑器里看起来究竟是怎样的？

这实际上是你们一开始看到的对话结构，可以看到，这里每个红色节点代表一个部分，它们彼此连接并且形成了非线性结构，因为对话流程取决于OB欧宝体育电竞官网的选择、以及他们在游戏里做出的行为。

所以，为了管理这种本地化，我们必须创造一种脚本格式和一个能够反映这个结构的工具，让翻译和总监能够看清对话流程。例如，当你录制配音的时候，在相互连接的部分之间，不会有特别大的情绪变化，我们的脚本格式就是这么形成的。

它实际上在《ob电竞》的时候就已经被创造出来了，随后取决于项目的需求不断研发新功能。脚本包含可拓展的上下本，所以我谈论的元数据是从脚本编辑器导出的，旨在为我们的供应商提供帮助。

不过，最为重要的是，脚本包含超链接，可以直接镜像到之前提到的图表结构。通过这些超链接，你可以在相互连接的部分之间直接跳转，这样你可以始终知道恰当的恰当逻辑流程。我们快速看一下我们的脚本长什么样：

有些栏里的东西是被隐藏的，这里有很多的元数据，从左侧开始，有字符串ID、场景名字、部分命名，对话层级，还有讲话人、总监的评论、场景评论和对话内容。最后还有VO文件名，这样工作室就知道如何向我们提供文件。我们还有超链接，点击之后会跳转到相邻的部分。

可以看到，你能知道对话的逻辑顺序，当你翻译或者录制的时候感到迷失，任何时候都可以检查它与什么是连接的，你甚至可以用超链接回到开始的地方，因此，它对于编辑和艺术总监都很重要。

现在我们来谈谈一个帮助实现更高本地化品质的辅助系统，也就是动态嘴唇同步。同样，我们从《ob电竞》开始就在使用不同的解决方案，因此核心概念也是相同的，《ob电竞》用了Jali，概念是为每个语言动态化生成嘴唇动作，它是基于文字、配音文件以及目标语言的具体词汇。因为，每个语言的发音，都会有不同的嘴唇动作，比如波兰语和德语就非常不同。

这还可以为录音带来更大的自由度，因为你不用重复增加嘴唇动作，还可以防止视觉效果与音频之间的不协调，不用像古老的中国电影那样嘴唇动作与演员说的内容不符。

接下来展示一段它在游戏里的片段：

我们为《ob电竞》研发的另一个辅助系统，是为Kiroshi和母语角色的标记语言。我们在《ob电竞》世界里有自动翻译技术，所以，如果有人说了不同语言，就会自动翻译为听众的母语，这让我们创造了一个多语言大都市。因此，我们需要确保它在代码和我们的翻译配音以及嘴唇同步管线都得到支持。

右侧是我们的一个案例，这里是英语和中文的简短对话，可以看到，实际的语言将Creole文字从翻译中区分开来，将目标语言呈现给OB欧宝体育电竞官网，还可以为嘴唇同步工具提供信息，比如角色实际上来自法国，所以我们需要提供法语词汇。

对于配音管线，我们在Perforce有一个通用文件夹，当我们录制Creole、中文或者日语对话的时候，它们就被放到通用文件夹内，然后在所有语言版本中使用。

我们还教供应商如何使用这种标记语言，这样，当我们发送给他们翻译内容的时候，他们就可以提供解决方案，再次简短展示一段游戏内容：

可以看到，NPC角色保持不变，而OB欧宝体育电竞官网角色可以从英文到中文切换。

现在，我们来说说日常用的本地化工具，我们称之为The Kittens。我比较喜欢狗狗，但对于这个名字并不介意。它从2017年就被创作并不断发展，当时我们招到了首个全职本地化程序员，我们用它来做日常工作。

我们创作了Loc-kits，我们称之为导出，我们将翻译导回到数据库里，创造迭代对比，进行LocDB搜索，我们可以编辑本地化字符串，还可以从仓库部署、播放、移除或替换配音。而且，我们还可以创造特别的导出，比如配音完成、单个角色导出。

我不会展示这个工具的所有功能，因为需要很长时间，但它看起来是这样的，这是它的主窗口，接下来用一段动图来展示部分功能：

我的部分这里基本就结束了，随后Tommi会告诉你们它是如何运作的。

《ob电竞》的本地化技术

Tommi：

我是Tommi，我要分享的是这个管线的技术方面。我首先会展示这个技术的概览，然后说这些工具的一些具体方面。

不过在此之前，我们先从团队开始。在《ob电竞》研发期间，本地化编程团队实际上是音频团队的一部分，这个团队由Colin Walder领导。团队是技术很小，平均只有两个人，现在也只有4个人。

那么，我们的职责是什么？基本而言，主要目标是部署Mikolaj刚刚谈到的工作流，他是我们的老板，是整个管线的所有者，我们需要遵守他的要求，意味着我们需要做本地化工具和管线。我们还负责配音管线，让配音文件交付到后期处理，最后交付到游戏里。

对于Jali嘴唇同步系统，我们以特别配置的文字和音频文件形式提供了原材料，我们还需要处理相关的游戏引擎代码，比如加载本地化资源到引擎里，我们研发了游戏系统本地化管理器，可以让其他系统请求本地化数据。

最后，我们与研发运营团队合作，创造在游戏里使用的档案文件。

我们的本地化技术已经做了很多年，我们发现了优秀本地化系统的五个特点，在这里希望展示给你们，我称其为“伟大金字塔”。

我们先从金字塔底部开始，你需要知道自己工作用的技术、了解与之一起工作的人，你要知道游戏环境上下文以实现更好的本地化质量，在项目的后期，系统必须通过更多的数据拓展，然后，是尽可能多地自动化。

金字塔底部可以给你带来研发速度的提升，顶部则可以提高本地化的质量。上下文环境通过内容质量带来质量的提高，缩放与自动化可以加快内容迭代速度。

我们来进一步看金字塔底部，也就是研发速度。这里主要的点在于，本地化数据是简单的，都是字符串和wav二进制文件，将这作为你的优势，高度优化的代码是必须的，保持简单。你需要知道你的数据结构和算法，让一切变得线性化，这可以带来更好的架构，更快的部署和更容易维护。

如之前所说，我们的项目本地化需要接触多个领域，这对于决策是很有帮助的。基于职业与不同领域的负责人建立关系，必要的时候进行清晰的沟通，你会慢慢发现，多部门合作不需要惊喜，更需要保持同步和信息透明。最后，考虑本地化话题的时候，你可以影响项目决策。

接下来是金字塔顶部，也就是本地化质量。本地化品质的主要资源是项目提供的所有元数据，就像前半部分分享展示的那样，你给翻译或者录音工作室的信息越多，你得到的反馈结果就越好。

这些元数据有些时候可能比较难以收集，你能够参与的越早，工作就越容易做。如果你需要在项目尾声的时候才开始收集数据，当引擎已经准备就绪、系统已经锁定，你很难要求其他部门专门为了数据收集进行特定的修改。所以，我们交付的上下文信息越多，就可以从翻译和配音环节得到更好的结果。

规模化意味着你的系统可以处理预期量的游戏数据，如果是3A游戏，它需要处理很多，或许对于更小的项目，就没那么重要。规模化主要的优势在于，你可以更快速迭代。当系统规模化和自动化之后，内容可以更快速重写，这就会带来更高的质量，因为你有了更多时间打磨，并且处理这个环节可能出现的bug。

自动化就是我们称之为“锦上添花”的东西，意味着策划有了更多的时间做更重要的是，而不是将其浪费在繁琐重复的事情上，比如复制文件到另一个地方，或者做QA以及验证等等。而且，自动化还可以带来连贯性，意味着它可以消除随机错误。

管线

说了本地化技术的原则之后，我们来看看真正管线的概览。

我们的任务是3A游戏的本地化，内容是在编辑器内创作的。然后是本地化工具，Kittens处理实际的本地化工作，本地化文本和元数据存储于本地化数据库，配音数据存储在Perforce。最后是build系统，它连接所有的组件。

我们曾经在《ob电竞》研发期间预测，大约有100人为本地化数据带来了贡献。当我们整合游戏里的台词数据的时候，得到了系统需要追踪的文本和配音量。综合两个数据来看，意味着每天要编辑200个以上的本地化数据，意味着我们的系统规模化和自动化做的很好。

Build系统和Kittens是用C#写的，本地化管理器和其余引擎是用C++编写，数据库是在SQL服务器之上使用Entity Framework 6.0部署。在分享过程中，我会不断提到哪些方法对我们很好用，哪些是通过艰难的教训学到的经验。

首先要说的是，本地化数据很简单，也很容易生成，在一些二进制wav文件上生成随机字符串很容易。在项目最开始的时候，生成足够多的数据，这可以让你提前测试自己的系统，这样，到了项目最后的时候就不会对那么多的数据量感到惊讶，你和制作人都会比较满意。

再来说Kittens，我听说它的名字来自于一个CAT小工具，全称是计算机编辑翻译（computer edit translation），所以，小猫就是Kittens，我也不知道这么解释是否准确，有关的故事很多，但可能真正的原因只能是个秘密。

Kittens是通过C#和WPF部署的，我们遵循了非常基础的视图模型方案，用了非常基础和简单的部署方法。

如果看这张图片，它是2010年的，或许比较值得一提的是，我们使用了Prism框架作为与build模型之间的通信。比如，当用户选择一些场景和语言的时候，对话使用Prism事件得到这些信息。

我们努力使Kittens保持轻量化，因此我们有不同的用户模式，比如完整模式、音频策划模式或者只读模式，我们试图只加载需要的模块。所有的Kittens只需要几秒加载用户界面，所以我们所有的主运营都可以在单独线程很自然地运行。

一个不太好用的方法是，在他们使用Kittens进行Perforce操作的时候，我们使用了用户自己的Perforce账户，这导致了太多的变量，比如，有些用户可能有非常复杂的工作环境、配置，加上COVID导致的居家办公也给我们带来了问题。所以，最好是专门有一个Perforce账户处理所有这样的操作。

Build系统

简单来说，Build系统就是一个在远程机器上运行C#可执行文件的系统。这些可执行文件从其中一个管线组件获得输入，然后将输出传递给其他组件。我们的Build系统是研发运营团队在.NET技术基础上制作的。

在这个系统中，用户可以设定运行，或用可选的参数手动启动，他们还可以为这个流程订阅邮件通知。

我们的心得是，当你做这些简单的可执行文件时，一定要保持简单。有些时候，在项目最后，所有人的工作都整合在一起，如果它出错，就会导致多个子系统出问题。

数据库

我们在这里存储所有的文本相关元数据，包括所有的历史和不同版本数据。我们是在SQL服务器基础上运行Entity Framework 6.0，我们有一个IT部门建立的远程服务器，他们负责数据库建立、用户优先级和备份。

我们从数据库请求的基础数据单位是一个场景，一个场景通常包含50-150行对话，这些台词的所有的元数据，包括台词历史、不同版本等，这只需要一秒钟的时间。不过，在这一秒钟内，会有大量的开销，因为我们在使用远程服务器，所以，请求一个10到20场景所需要的时间需要几秒钟，因此远程服务的性能开销是主要问题。我们的数据库查询是线性的，所以它的开销不大。

使用Entity Framework，我们也有一些心得，我们禁用了LINQ拓展，因为这会导致nested joint statement。相反，我们使用Foreign Keys处理数据库关系，目前为止，这个方法可以带来最好的性能。

不过，对于这个工具，我能给你最好的建议就是升级到7.0，这个版本有很大的提升，不仅解决了上面出现的问题，你还可以使用LINQ查询。

这里我们学到经验是，不要在数据库层面删除任何东西。因为，有一天某个策划可能会找到你，说这个东西很不好用，然后请求删掉它。但过了几个月，同样是这个策划，他可能告诉你，这是最好用的，现在把一切都恢复过来，如果你删除了，它就不存在了。

我们还发现，在项目收尾的时候，如果我们没有删除任何东西，那么数据库的大小只是增加了20%左右，并不会影响数据库的性能。

其次，使用这些Profiler可以让你看到LINQ查询和SQL查询，在C#代码中，你的LINQ可能看起来很好，但它在SQL层可能会有些问题。因此，在做任何事情之前，最好是检查一下。

对话管线

我们的目标是从编辑器获得本地化文本，把它们放到本地化数据库和游戏内。保存一个场景需要创造一个JSON文件，将其提交给Perforce激活一个submit trigger，然后它启动处理这个JSON文件的过程，并将本地化数据存储到本地化数据库。这些submit trigger非常好用，它是我们build系统所有自动化的基石。然后我们得到新翻译语言，让它出现在游戏里。

我们称build系统创造的内容为depot或archive，depot是用于编辑器研发版本和游戏的文件，archive则是我们为最终PC或主机build使用的压缩版本。

配音管线

配音和录制，和其他一样，一切都从Kittens开始，我们将录音文字发送给录音工作室，然后我们得到录音显示和录音文件。

比较酷的一件事是，你实际上可以直接为wav file header写东西，当你在管线做自动化的时候，这可以带来很大的帮助。

我们得到录音文件之后，本地化经理用Kittens将其提交给Perforce，我们的录音工作室做了大部分的验证工作，所以我们验证的过程很轻量化，基本就是检查文件名、文家大小，以及wav文件是否包含了一切内容。

然后，我们的音频策划使用Kittens下载配音文件，请求后期处理，随后提交给Preforce。

最后是配音从Perforce到游戏的管线。我们对build系统应用了一个标准化步骤，从whisper到shout我们有六个预定义关卡，对所有文件应用300 ms pre/post silence。没有后期处理的文件，是因为音频策划在后期处理的时候对它们应用了mastering。这个词汇看起来有些奇怪，不过，Mastering是去噪和均衡处理的一种。

《ob电竞》为音频使用了WEM文件，所以我们需要将所有的wav文件转换为wem文件。对于Jali，所有的wav文件与嘴唇同步保持一致。

我们做的事情有些过犹不及，比如在Perforce存储了太多的wav文件，一度达到了4.2TB，我们的IT部门对此很不开心。

本地化管理器

引擎内管线是通过一个本地化管理器系统来处理的，它通过Singleton API简单部署，运行方式是场景系统用本地化key请求内容，然后基于这个key返回内容。我们有多语言设定，意味着你可以有不同语言的配音和字幕。

文本的内存占用大概为4M，我计算过，实际上可以控制在2到6之间，我们其实还可以做的更好。

随后加入配音，对于游戏内对话，我们没有runtime配音后期处理，我们的音频策划线下做了很多个版本，然后场景会根据需求请求一个具体版本。

以上就是技术部分的内容，之所以选择这张图作为结束，是因为随着新资料片的推出，我们会废弃这个管线，但所有的经验和心得都会运用到新管线中。之所以说废弃，实际上很多东西都保持不变，我们只是为新内容做了一些新工具。

方法总结

最后，我希望分享一些成功故事和短板。

成功1：技术和本地化部门合作

第一个成功故事，就是技术和本地化部门之间的合作。我们在非常短的时间里做了很多的事情，其中最关键的就是直接沟通，一切基本都是面对面完成的，没有很多繁琐的流程。即便是非常困难的决策，也都是面对面直接沟通做出来的，简单而言，当我们有问题的时候，就一起解决它。

之所以能这样，还有两个原因，所有的问题都是我们一起拥有，我们有个不成文的规定，那就是没有本地化问题或技术问题，这些都是我们需要一起处理的问题。很多时候，尤其是发布游戏遇到挫折之后，我们基本上都是坐在一起解决问题，而不是将问题抛给对方。

另外，本地化团是非常热情的话题发起者，他们对话题非常了解，并始终寻求如何提高，这让技术团队与他们合作非常有成就感。

短板1：管线透明度

一个短板在于，我们的系统不够完美，有些东西需要提升。本地化管线经常有可视化问题，让用户不确定他们处于哪个阶段。还有一个经常出现的问题，是不确定哪些改变是可用的。这些问题的根本原因在于，管线分散于build系统，但并不是所有员工都能使用Kittens。

这个问题尤其是在项目后期比较明显，当时内容已经打磨好准备交付，策划当时在做某一些台词而不是整个场景，对于我们的新系统来说，这将是很重要的设计点。

成功2：韩语配音

这是一个来自游戏研发的经典“战争故事”，因为，当时是游戏发布之前的六个月，董事会找到我们说，“我们在游戏发布的时候加入韩语配音吧！”然而，我们做其他语言已经有一年多了，所以不得不快速反应，找到演员并开始录音，确保配音与台词同步，最好还要留出时间做本地化QA。

我们用了三个时间录制了整个游戏的韩语配音，这是很不可思议的，感谢我们的LPM和韩国合作伙伴，实际上我们还保持了比较高的质量。提到这个，我想说的是，我们打造的系统和管线非常强大，哪怕是在这么艰难的条件下，我们也能够快速反应。

短板2：迭代与自动化

我们提到过自动化，但是，当你自动化的时候必须小心，因为，有些时候事情并不会朝着我们想要的方向发展，我们的自动化管线出现了一些问题，比如，有时候配音播放的是旧版本，哪怕我们已经有更新版。

所以，本地化团队必须检查到底出了什么问题，结果发现，我们需要清理一些旧东西，比如过时的资源。这就需要技术团队设计新的辅助工具，因此，自动化虽然很好，但你需要留意一些极端情况，它可能会带来额外的问题。

心得

从我这部分来说，最主要的心得之一，就是与单一语言的供应商合作，与团队成员直接交流，这样你才能知道并影响发生的事情，如果有些事情出错，你就可以快速做出反应。

其次，如果你知道团队里有人知道你正在本地化的语言，让他们参与其中，同时供应商一起工作，让本地化做到尽可能好。此外，与真正创作那些你需要本地化内容的团队合作，让他们知道，哪些内容需要被本地化，让内容团队提供一些上下文环境，确保得到的内容便于供应商进行本地化，因为没有人希望最终游戏里都是bug。

另外，就是与创造工具的团队合作，确保这些工具真正满足你的需求，那些管线能够真正是你要的样子，因为这对于本地化来说很重要。

Tommi：

我的心得，最主要的就是本地化数据很简单，要把它作为你的优势。你的系统可能会有很多其他东西，但最主要的就是字符串和二进制文件。在此之上，由于数据很简单，创造数据也不复杂，因此要创作足够多的数据预先测试你的系统。

最后，本地化覆盖多个部门，尤其是在我们公司，所以，和所有受本地化影响的部门合作。