干货 | 携程国际化进程中，是怎么做站点多语言处理的？
作者简介
祁劢，携程国际业务部内容研发团队Leader，目前主要负责信息类项目产品设计、技术架构与团队管理。CG爱好者，喜欢细致描绘世间百态的通俗小说，喜欢探索，乐于体验各地风土人情。
一、项目背景
携程国际业务部门（IBU）是携程多语言站点的研发及维护部门，主要面向国际客户提供携程优质的产品与服务。在国际业务部门研发的众多信息处理产品中，IBU内容研发团队的携程内容翻译平台-CTran，主要负责对酒店、机票等业务的内容信息进行多语言处理，为携程国际化提供支持。
作为CTran系列的产品设计与技术架构，我与团队一起经历了CTran项目的演进与革新。
CTran目前最新的V3版本于2018年年初正式上线，是经过重新设计和整体重构的技术产品，其设计既是对以往解决方案的反思，也希望通过技术建立新的流程，解决当前面临的业务问题。
在此与大家分享我们实现CTran V3收获的经验，希望我们推进国际化内容建设的阶段性成果，可以给本部门同类项目，以及行业同类需求提供借鉴，共同促进业务发展。
二、国际化面临的语言问题
携程中文系统拥有海量的中文旅游类商品资源，为国内用户提供丰富的旅游服务。IBU主要面向海外用户，如何合理利用中文系统的资源宝库，为海外用户提供优质的无语言障碍的服务，是一个难题。
从多语言转换的难易程度来说，结构化的信息是易于进行多语言转换与维护的。
然而，携程中文数据主要面向国内用户，其业务数据形态设计上并没有考虑过翻译转换的成本。由于旅游商品的特殊性，存在大量的非结构化信息需要转换，虽然信息维护部门也意识到了非结构化信息对国际化的影响，但由于种种原因，信息的弱结构化甚至非结构化的情况仍然较为普遍。因此，IBU需要针对多语言转换需要重新对数据进行规整与清理。
此外，信息是持续变化的，为了给用户提供确切的多语言产品信息，需要积极同步源信息的变更情况，及时进行翻译转换。
携程的旅游产品可以略分为机票和酒店两个方面。机票由于数据自由发挥的余地较小，常规静态信息居多，多语言化较有优势，酒店数据情况则相对较复杂，对于一个酒店类商品，要达到能销售的程度，需要投入较多翻译资源对非结构化的数据进行处理。
CTranV3多语言翻译平台承担了机票及酒店内容信息的多语言翻译任务。对于机票业务，目前覆盖处理的是政策类资源的翻译，主要通过实时翻译接口直接为用户提供服务；对于酒店资源，比较关注数据的变化，主要通过离线方式进行多语言翻译处理。
三、CTran V3介绍
1、概要
CTran V3整体结构如下：
图1 – CTran V3整体结构
整体而言，数据流入V3后，经过离线或在线的翻译处理，再通过各种输出接口流出。
暂时未能自动化翻译处理的数据，将由翻译人员介入，通过V3提供的翻译辅助、内容分析等工具，译完后输出。翻译人工维护的结果也将将通过多级词库的形式存储到V3系统中，用于将来的批量处理等流程；对于线上的翻译错误，V3也提供了高效的数据修正手段，方便大规模数据修正与多语言信息质量提升。
具体业务方面，酒店相关资源的翻译流程首先经过数据转换，通过离线方式翻译处理后，推送到IBU的酒店相关信息数据库，最后在线上呈现。机票、铁路等其他可以实时转换的信息，由调用方直接请求V3实时翻译服务，获得翻译结果。其他静态资源，则可以通过文件任务接口，利用V3的翻译辅助等进行处理，翻译流程结束后，再以文件形式获得翻译结果。
以上是V3与外界交互的几种主要形式。下面主要以酒店相关信息的翻译为例，介绍V3是如何对数据进行翻译转换的。
2、酒店数据流入
酒店数据的多语言翻译是从数据源头开始关心的。CTranV3通过数据同步，持续跟踪酒店业务数据的变化。数据信息经过适当转换后，通过与自身存储的中文酒店信息镜像进行比对，识别差异，对“内容变化引发需要翻译”这个事实作出判断，生成翻译请求。
数据的同步由Ctran V3的子项目——多语言数据服务（Langs）负责完成的。Langs主要职责除了获取数据外，还用来接受V3翻译服务的酒店数据翻译更新推送，并负责确保将其推送到IBU的Online信息数据库，以完成业务信息上线。所以，Langs是翻译服务与数据源、多语言业务方之间纽带。
Langs同步信息处理的第一步是对业务数据按类型进行拆分，包装成统一的对象后，通过消息队列推送给数据比对模块。数据比对模块基于内容变更情况形成的需要翻译与否的判断，相关功能是通过表驱动(Table-Driven)的形式实现的。
所谓表驱动，即通过配置表定义运行逻辑。数据变化形成状态变化，各种状态组合形成状态集，通过状态集可以设定具体的操作。Langs首先对状态进行判断，组合状态后查表找到对应的操作集合，按配置进行数据处理。
众多变化中较为核心的是内容的变化。在获取数据后，Langs首先依照特定规则对数据进行清理，归整成特定的形式，在不影响语义的情况下再做一致性判断。
内容数据变更的判断并非是简单的文本相等比对，举个简单的例子，如果名称里出现一些符号，对于特定类型是不会影响语义的，也就不需要重复进行翻译，因此可以将一致性判断的条件放宽。类似这样的对特定类型的判断规则有很多，其目的也是尽量减少翻译所需要处理的数据量，降低翻译成本。
比对的结果会形成具体的状态，类似“有变化”，“无变化”等。某些情况，文本数据的“置空”可以视为一种逻辑删除，也被独立表示成一种状态。
状态变化与操作的配置表，在概念上可以如表格所示：
中文变更 | 英文变更 | 状态变更 | 行为1 | 行为2 | 行为3 |
有变化 | 有变化 | 有变化 | 更新中文 | 更新英文 | 发送待翻译消息 |
无变化 | 无变化 | 无变化 | 无需操作 | 无需操作 | 无需操作 |
… | … | … | … | … | … |
表1 - 表驱动配置示例
其中，黑底色的列是状态组合，白底色的列是对应的操作集合。通过结合Java枚举类型及Spring Bean注册机制，在项目内创建特定的Bean，利用Spring对于类型Bean的自动发现机制同时获取Java Annotation的元信息配置，自动将代码逻辑与数据库保存的配置表建立关联。
表驱动的设计提升了逻辑处理的抽象程度，更重要的是，由于操作逻辑的外露，通过良好定义的行为说明文档，许多也许需要写在代码中的If / Else条件判断也可以由非技术人员，比如运营人员，通过Excel进行调配。由于规则本身具有较强的描述性，查询日志即可明白某条数据是如何被消费与处理的，便于错误排查。当希望获取周期内变化情况时，仅需要根据特定的规则组合查询日志即可，也很方便。
类似这样业务逻辑配置化的例子在V3中还有很多，对于有调整变更需要的模块，这样的设计一定程度上帮助提升了软件的可维护性。
3、翻译任务
CTran V3的翻译是以任务为单位的， 作为一个维护着上亿数据的翻译平台，当数据规模超过了团队能够处理的极限，就需要对数据进行规划，有重点的投入翻译力量，有先后的进行翻译。
常规做法一般是预设优先级，并且将这样的优先级直接与数据绑定。旧版CTran在最初数据较少的情况下，也是这么做的，导致当数据大规模增加时对优先级进行调整的困难。
因此，V3并未对酒店数据本身做优先级标记，而是通过另一种方式对待所维护的数据。优先级的最终目的是筛选数据，所以，如果能够支持不同的条件组合，对大规模数据进行快速搜索过滤，也就可以实现优先级的动态调整。
这样，优先级就变成了一种搜索/数据筛选的配置，修改优先级也就是修改搜索条件。之后，在过滤好的数据集合之上，译者可以自行决定任务规模，制定翻译计划。
图2 – 数据筛选
为了加速搜索，V3通过一些常规的工程手段，比如简化数据存储，适当冗余数据，优化数据库索引，混合Elastic Search搜索引擎，将分页搜索改为上下翻页搜索等策略和技巧，对酒店合理业务需要的搜索条件组合进行针对性的优化，保证了数据定位的速度。
在可以快速进行搜索后，就需要定义优先级配置文件了。所谓优先级定义文件就是一些维度条件的组合，比如酒店所在城市、星级、类别、子母酒店规则甚至酒店基本ID本身。
而优先级定义文件的来源可以是用户上传或者BI统计的用户PV酒店数据、主动定量分析等方式形成。支持动态优先级以后，运维即可以通过交互的方式，查看在某个维度下数据分类的情况，安排翻译计划。
图3 – 优先级选择示例
获得数据过滤的结果后，要进入翻译流程，还需要再确定一下翻译的范围。
V3允许根据用户工作计划设置自动或者由用户手动的决定一个任务需要包含的待翻译数据范围。自选数据加入任务包，类似网上购物“加入购物车”的概念，并且流程上允许在形成的任务包上进行数量调整或者部分优先完成，保证了工作的灵活性。
翻译人员在平台的操作一般流程可以归纳为：选择数据，创建任务，进行翻译。简单而直接。
除了常规的翻译辅助、内容校验等支持，以任务为单位的V3也很注重译者的协作。借鉴类似IM软件建群的方式，V3允许翻译人员自由组成多个翻译组，并且不限制个人加入组的数量。任务包将在译者所加入组的成员间流转，方便了翻译内容的校审与协作。每一步转移均会有相应的图形化呈现及日志记录。
可以看到，常规流程可分为“收集->翻译->校审->完成”几个阶段，通过允许“重分配（Reassign）”这样的转换，可以方便的支持多译者间翻译任务流转。校审阶段依照设置也是允许退回操作的。这样的设计为翻译基本流程提供了足够的支持，足以覆盖绝大多数情况。并且，我们在业务上允许译者将翻译任务包进行拆分，提交已完成的部分，确保了任务完成的灵活性，日志记录及图表呈现会忠实呈现各种状态迁移。
图5 – 翻译流转图形表示
数据变更方面，V3利用公司的大数据存储，通过有效设计事件日志，对所有影响线上的数据变更情况均记录有日志，通过合理的事件记录，任何变更都有迹可循。
4、数据分析与报表
要处理数据，首先要了解数据。
CTran V3对接了携程的大数据处理平台，进行各种常规数据分析，帮助译者、运营及研发了解数据。常用的分析手段包括利用自然语言处理工具对句子按句法边界、词法边界进行拆分，统计频率，句式模板识别、关联数据翻译情况分析等，同时也会对翻译情况等生成统计报表，反映现实状况。
图6 – 数据分析
V3在处理全量数据分析的同时，结合上面提到的任务的动态优先级划分，也会自动对用户划定范围的数据进行分析，所有的动态优先级条件划分均可以作为既定范围进行分析操作，以便用户可以有重点的看到分析结果。分析结果在V3中提供展示，并通过各种辅助工具帮助翻译人员识别特征数据，重点翻译特征语句，调优V3自动翻译规则和算法。
翻译情况统计报表会按时间跨度自动预聚合，以方便在不同时间跨度查询下仍然保证查询速度，又能够进行足够精度的范围查询。目前支持从小时到按月等维度进行数据查询。统计报表不仅会通过Dashboard在V3中展示，也支持通过邮件的形式发送给运营人员。我们在公司邮件服务的基础上，建立了支持自定义收件人组合及邮件模板维护的邮件发送平台yeMail，用以解决相关问题。
虽然从数据规模上看，V3所覆盖的数据不过千万级别，但我们设计各种数据分析通路其实也是为未来铺路。解决自然语言翻译这样的问题绝不能只着眼于V3目前维护的数据，一定要广泛利用各种数据来源，有针对性的尝试各种可能性，设计各种流水线就是为了方便这样的处理。
5、翻译引擎的工作原理
CTran V3处理批量翻译的另一个手段是使用自研的翻译引擎。V3的引擎不同于通用的翻译引擎，不是为处理未知形态的数据翻译而设计，通用的翻译引擎也并不适用于携程类型化的翻译。
V3所有翻译处理均是在数据类型确定的前提下所编写的转换逻辑，务求确保翻译准确。由于自然语言处理的特殊性，并不存在唯一的在所有场景下均能在各方面都取得良好成效的解决方案，所以我们按照情况对翻译逻辑器件进行调配组合，通过责任链共同构成现在的翻译引擎。常规实现可分类如下：
1、基于句式模板的翻译；
2、基于模糊匹配的翻译；
3、基于词拆分的翻译；
4、依照类型的业务类型的一些多级词库优先取值规则；
基本原理是对内容的逆模板化。酒店数据等等已经设定好分类类型的数据往往包含一些可以枚举的成分，比如城市名称等信息。这些可枚举的成分即可作为可识别的对象，依据类型进行变量替换，并且编序。
变量替换之后的内容，即为句式模板，依照句式模板找到数据库中对应的翻译模板，然后再对可枚举的词进行词库查找，依照语法规则进行形式变化、对位替换后，即可产生翻译结果。
这种操作由于模板的特性，会受输入内容影响，导致语义相近的句子需要建立多个模板进行映射。由于相似度并不能确定性的定位一个无法满足全匹配的模板，我们目前使用的手段是通过一些预定义规则对模板化前的数据进行清理归约，等价替换，以降低其多样性。
这是通过已有的规则去尝试套用到给定句式上，找到匹配后进行翻译的手段。适用于可识别的变量需要枚举的量过大的情况。通过模糊匹配找到对应的模板后，再对有差异的成分进行提取，尝试转换后使用译文词典翻译找到映射后再合并处理。
主要有两种方式较为常用。第一种很直接，主要通过基于词典的分词器对传入内容进行拆分后，根据预定义的多语言类型词典，依照人工翻译规则确定不同语言的排序，然后适当转换后形成翻译结果。
另一种是通过识别短语中心词，然后依照中心词拆分，分析成分后翻译转换输出。前一种主要在携程的基础房型翻译中使用，后一种则针对国内地址等这样中心词（字）特定的类型比较有效。
V3中多数翻译器对数据的处理过程均是可见的。诸如模板等翻译组件需要协同译者利用她们的专业知识帮助完成。V3通过暴露翻译器的中间数据结果让译者理解翻译器的工作流程，针对不同引擎的特性输出不同的中间解析结果文件，方便译者依照情况进行翻译调整，进而提升引擎的能力。
10、内容构建支持
酒店描述随意性较强，对翻译造成一定程度的困难。通过识别句子边界找到翻译模板进行多语言化也许有一定效果，但并不是最有效率的手段。
考虑到大批量的数据缺乏可能造成的搜索引擎收录排名的影响，适当采用内容构建补充数据也许是一种可行的方式。CTran V3的酒店描述生成即是从数据构建的角度试图解决多语言信息完整性的问题。工程上这样的方式在游戏产业尤其是角色扮演游戏中比较常见，其原理是通过一些数值信息，联合内容模板，依照某种条件的选取策略，最终输出整体内容。
图7 – 内容构建
V3借鉴了这种方式，通过酒店关联信息以及内容模板，依照既定条件随机拼合，用来创建酒店描述。
酒店信息包括周边景点、商圈、车站等，利用各种地理信息与其他量化的信息做模板选择，只要通过不断维护关联内容模板就可以对酒店描述不断调整与更新，并且内容也是可控的。
这种手段的缺陷是生成结果比较生硬，句子间缺乏过渡，上下文关联不紧密，数据随着规模上升，重复度较高。由于其信息多少在酒店本身有一些涉及，整体可读性也不高。但是，相信随着自然语言处理手段的进一步使用，数据构成的进一步丰富，这类生成信息应该会提供更好的阅读感受。
图8 – 模板配置
11、Job管理
CTran V3需要周期性的对数据进行大批量操作，需要有可靠易用的任务调度平台。我们跟随着携程的技术步伐，先后使用各种Job平台对数据进行批量维护，也经历了一个从自研Job管理软件到将信任托付给携程通用调度平台的过程。
V3当前主要使用携程的Job调度平台Qschedule进行Job调度。Qschedule下维护的V3相关Job已经超过70个，分别对数据的状态一致性、批量翻译、索引重建和缓存更新、词库定期快照等诸多方面提供支持。Job的数量随着时间推移还会不断增加，为了合理对Job进行维护，IBU内容团队定义了Job编写规范，可以让活跃Job自动登记到V3平台中，方便对Job进行分类维护。
9 – Job维护
Job在编写时使用了特定的Java的Annotation元数据标注，Job在运行时会写入统一存储，然后V3中即可读取到相应的配置数据，用以分组排列展示。
翻译更新等会涉及到频繁的扫表。为了降低大批量数据扫描对数据库操作的压力，V3对于数据定位方式做了两方面的优化。其一是通过各种预建的搜索索引定位数据，其二是在Qshedule的Job之上建立Job管理抽象，通过携程消息平台中间件Qmq消息进行触发。
当人工通过页面设置操作逻辑时，其实是在构建能够触发Job的Qmq消息。通过定期聚合待发送的Qmq消息，可以将时间窗口内的多个逻辑合并成一个具体的Job，统一运行，并且监控其状态。而且，相应的Job也是可以通过页面进行中断的。
12、实时翻译
CTran V3的实时翻译服务是由Flit子项目提供的。Flit是V3翻译引擎的对外服务接口。
Flit实时翻译服务为提升V3内部翻译引擎实时性做了多项优化。我们在常规算法优化的基础上，针对实时请求的特点，为翻译引擎建立了多级缓存。上线以后，IBU Online机票翻译99%的请求的响应时间低于5ms。
Flit翻译服务也为自动聚合未能翻译数据提供了支持。结合公司提供的大数据聚合分析功能，未翻译数据会自动进行聚合统计，在V3中形成待翻译数据列表、统计图等，通过邮件等方式提醒翻译人员介入处理。
13、静态文件翻译支持
CTran V3提供了以Excel文件为代表的文件导入翻译功能，可以通过导入Excel文档，交互式指定原文列的方式进行翻译任务创建。
图10 – Excel任务创建
Excel在V3中不仅可以作为任务本身，也可以作为离线翻译的手段。对于酒店类型的常规翻译，通过Excel将任务导出/导入也可以看成是翻译流程的一部分。也就是说，任务翻译不仅可以通过在V3页面上进行，也能随时导出成Excel文件，通过操作后再次导入更新翻译的方式进行。工程实现上，为了支持Excel处理，V3对Apache POI（Excel操作库）的流式读写、配置式内容读取等做了很多实用的工具类包装，方便了业务开发。
四、写在后面
CTran是IBU国际化进程中诞生的数据处理方案。V3是在深入理解了IBU、携程数据的前提下，为改进业务流程，从存储层、核心实现到用户交互彻底重构的产品。
在紧缺的翻译及研发人力资源配置的情况下，V3的功能设计是克制而务实的，力争合理用好每一分资源。架构上我们采用了很多的携程自研基础框架。有强大的公司技术作为后盾，研发工程师才能心无旁骛的投身于业务解决问题方案实现。
重新设计的CTran V3希望通过简洁直观的设计，展现工程师的细致与对效率的追求，让良好架构的产品与用户共同成长，让机器与人更好协作。
V3于2018年1月17日上线至今，用户整体反馈良好，更令我们欣喜的是，翻译人员、运营团队、产品经理等用户与平台研发的互动越来越频繁，显然她们理解了V3的技术设计，依赖技术，能够对产品的不足提出自己的想法，帮助我们创造更有效率的工具。
国际业务内容研发团队所有产品的研发策略有别于其他业务类团队，从功能的设计取舍到技术架构的调整均由研发团队直接把控。我们尊重并积极收集各方反馈意见，自我驱动持续迭代，保证了项目的专业性，也鼓励研发人员对用户体验与业务意义的思考与主动发现。内容团队欢迎各方对我们的产品提出改进建议，支持我们的工作。
技术是驱动业务发展的核心力量，好的技术不仅以人为本，关心业务价值与生产率提升，还应该为用户的想象提供助力，为产品改进提供方向与信心。
【推荐阅读】