自动检测、校正和翻译非本地化行的方法与流程

本申请是2016年09月20日提交的序列号为no.62/397,051的美国申请的国际申请并要求其优先权，其内容和附图通过引用全部并入本文中。本发明涉及一种用于自动检测非本地化代码行的方法，并且更具体地，涉及对能兼容应用程序打包标准(aps)的应用程序接口中的代码行的检测、校正和翻译。
背景技术：
：服务自动化系统需要大量的能兼容应用程序打包标准(aps)的应用程序。应用程序打包标准(aps)是一种标准，该标准定义了用于将应用程序软件与托管平台集成在一起的技术。应用程序与这样的托管平台的集成是通过为该应用程序创建aps包来实现，并且在这种情况下该应用程序被称为aps应用程序。在aps平台上的开发允许应用程序通用于不同的托管平台上。这些应用程序也以当地语言和/或方言配置在世界的各个地区。为了使用这些应用程序，有时使用当地语言来配置其图形用户界面(gui)。例如，当gui呈现给美国(u.s.)的用户时，gui可能具有英语的文本元素，当呈现给俄罗斯的用户时，相同的gui元素可以具有翻译成俄语的相同文本。对gui元素使用当地语言(与仅使用英语相反)可以实现定制和改进的用户体验。国际化(i18n)是开发应用程序的过程，使得字符串和其他的地区专属位(例如日期或货币格式)可以从应用程序中抽象出来，以便它们可以容易地针对语言和文化进行本地化。本地化(l10n)是通过为抽象出来的位(bit)提供翻译和本地格式来调整应用程序和文本以使其能够使用在特定文化或语言市场中的过程。例如，使美国应用程序对于澳大利亚或英国用户可访问可能需要多一些拼写校正。但是，为了使美国应用程序能够被日本用户使用，或者使韩国应用程序能够被德国用户使用，将要求该软件不仅以不同语言操作，而且还要使用不同的输入技术和呈现惯例。为每种语言和每个应用程序开发gui(以及其中的gui元素)不是可行的命题。在尝试在世界多个地区配置应用程序时，开发所谓的“语言本土化”gui所需的时间、精力和金钱可能会是非常繁重的。为了减轻负担，软件和开发平台(例如aps平台)允许gui元素被本地化和翻译。这允许gui在呈现时为该区域(或用户)的本土语言。但是，gui界面元素的传统翻译和转换呈现得并不一致。这可能是因为：包含一种语言的字母表的字符集与另一种语言不同；空间特征的变化使翻译后语言的文本更大(或更小)；或者有“在翻译中丢词”的含义。此外，当开发或改进gui时，在屏幕上呈现给最终用户的数据量可能增加，这包括用户看到的任何文本消息只是一部分gui。特别地，行的数量、界面元素的标记和屏幕形式都趋于增加。根据aps标准，所有应用程序界面元素都必须进行本地化和国际化。但是，在将界面行和元素包含在应用程序代码中之后，它们并不总是被正确地格式化。因而，最终用户可能会观察到由应用程序内部的消息的部分本地化和翻译引起的故障。例如，现在参见图1，示出了用于翻译能兼容aps的应用程序的非本地化行的传统方法(通常以100示出)的实施例。该传统方法包括收集源代码的步骤102；通过msgmake挂件(post)导入本地化的步骤104；创建可移植对象(.po)消息文件的步骤106；将msgmake挂件转送给为非本地化行起草译文的技术撰码人的步骤108；添加译文的步骤110；通过在javascriptobjectnotation(json)中导出本地化消息来构建aps包的步骤112；形成带有国际化文件的aps包的步骤114。在传统方法100中，并非所有行都可以被正确地呈现并本地化到界面中。其原因可包括但不限于：地区的格式不正确、处理器错误、不正确的密钥、缺少可用的译文，或者与另外地区有关的拼写错误或丢失文件，这里仅举几个非限制性例子。这导致所需方案的实施不完整以及与检查和校验相关的高成本。理想地，可以在应用程序开发阶段就防止上述问题。此外，需要自动和半自动地检查gui元素译文的正确性。这会有助于改进检查并降低与手动校验相关的成本。最后，需要一种在应用程序生命周期管理中及时检测本地化错误的方法。因此，需要一种用于自动检测、校正和翻译非本地化行的方法。技术实现要素：因此，本公开是针对一种用于自动检测、校正和翻译非本地化代码行的方法，其基本上消除了现有技术的一个或多个缺点(如下面进一步讨论的)。在本公开的一个方面，提供了一种用于在安装的应用程序被传播为消息文件(*.po)之前，定期检查应用程序源代码中的本地化行的方法。在另一实施例中，针对所有支持的应用语言提供对代码行的自动翻译。比对消息文件，来验证代码行及其提供在il8njson文件中的译文。根据示例性实施例，使用本地化标记在源代码中检查非本地化的行。根据aps，针对apsmsgmake实用程序使用特殊的陷阱(即钩子)，以便从用于安装用户界面的aps命令行工具的集合中导出本地化数据。附图说明图1显示了由技术撰码人手动翻译代码行的现有过程的示意图。图2显示了所建议的用于自动检测、校正和翻译非本地化行的方法的示意图。图3显示了用于自动检测和收集本地化样式的方法的流程图。图4显示了用于自动检测、校正和翻译非本地化行的方法的流程图。图5显示了用于自动检测和验证衍生行的方法的流程图。图6显示了用于自动检测、校正和翻译非本地化行的方法的示意图。具体实施方式现在将详细参考本发明的优选实施例，其示例在附图中示出。在本公开的至少一个实施例中，提供了一种用于在安装的应用程序被传播到消息文件(*.po)之前定期检查应用程序源代码中的本地化行的方法。在另一实施例中，为各代码行提供了针对所有支持的应用程序语言的自动国际化。比对消息文件(*.po)来验证这些行及其译文。根据示例性实施例并参照图2，使用本地化标记来标记源代码202中已本地化的代码行。在使用aps的实施例中，针对apsmsgmake实用程序204使用特殊的陷阱(trap)(即钩子(hook))，以便从用于安装用户界面的aps命令行工具的集合中导出本地化数据。apsmsgmake命令将翻译字符串提取到消息文件(*.po)中，每种语言一个文件。.po消息文件是纯文本文件，表示包含了所有可用的翻译字符串的单一语言及这些字符串在给定语言下的解释(译文)。此文件是翻译器以目标语言提供翻译字符串的译文的一种便捷方式。.po消息文件由许多条目组成，每个条目描述原始未翻译字符串与其对应译文之间的关系：msgid“[这里是原始翻译字符串]”msgstr“[这里是翻译后的字符串]”使用上面的例子，用西班牙语进行翻译可以表达如下：msgid"diskspace-usageonly"msgstr"espacioendisco-solamenteuso"根据示例性实施例，使用了两种示例性格式的钩子(即本地化标记)：javascript文件(*.js)java文件(*.java)_("消息")__("消息")*.java的一对下划线和*.js函数的单下划线为使字符串可用于翻译的钩子。例如，__(“要翻译的字符串”)使得apsmsgmake命令在.po文件206中创建msgid“要翻译的字符串”和msgstr“翻译后的字符串”。在一般情况下，字符串可能包含不应当被翻译的映射参数。映射参数必须包含在一对下划线“__”之间。在下文的示例中，msgkey字符串包含参数，这些值必须在paramobjects映射字符串中找到：_(msgkey,paramobjects)还应理解，本地化标记可以使用简短格式或完整格式。例如：javascript(*.js)：简短格式：_("user__username__created")完整格式：_("user__username__created",{"username":"johnsmith"})java(*.java):简短格式：__("user__username__created")完整格式：__("user__username__created",{"username":"johnsmith"})因此，所有这些行都被添加到.po消息文件中，随后添加到json中，如下所示：__()函数用于对字符串@msgkey进行本地化。例如，@msgkey实际上是字符串”found__itemscount__item(s)”。此字符串包含由一对下划线包围的itemscount参数。该参数定义成映射字符串{"itemscount"：counter}。因此，如果apsmsgmake在解析javascript代码时遇到以下代码：_("found__itemscount__item(s)",{"itemscount":itemscount})它会自动在.po消息文件中生成以下的一对记录：msgid"found__itemscount__item(s)"msgstr""得到的.po消息文件206被认为是正确的，并且被用作本地化样本(即，本地化样式)的辞典的基础。由于代码的可变性相当高，因此不可能高精度地确定要在产品源代码中待要本地化的行。根据示例性实施例，自动地考虑已经被写入到当地地区en_us.po的.po消息文件中的密钥的源代码行，并将其收集作为本地化样本。如图2所示，源代码分析器208可用于查看各种代码源202。一旦找到具有本地化标记的行，源代码分析器208将当前行内的本地化标记之前的所有内容保存到数据库(即数据库656)中：样式时间戳文件扩展名label:2016-04-100:00:00.000js以上记录称为本地化样式。例如，在以下内容中：varwarn＝_("assigntheservicenameservicetoyourselftostartusingit.",{servicename:serviceconstants.service_name}，该本地化样本会是"varwarn＝″。根据示例性实施例，基于多个规则生成本地化样本(样式)。在本公开的至少一个实施例中，如果*.java文件中的行包含文本常量(即文本“staticfinalstring”或“finalstatic”)的说明，则应用程序会将位于字符串之前的所有内容(包括实际单词“string”)看作为本地化样式。因此，对于字符串publicfinalstaticstringpassword_not_changed＝__("passwordnotchanged")，本地化样式是publicfinalstaticstring。当在本地化标记前面没有文本时(例如，在一个多行字符串中)，源代码分析器208将位于上面一行的所有内容作为本地化样式。如果上面的代码行包含带有本地化标记的字符串，则应用程序将移至上面的下一行。例如，对于行：本地化样式为：returnbuildnotification(apsaccountuuid,apsuseruuid,entity,domainname,notificationmessagestatus.inprogress).如果在基于已经生成的本地化样式进行搜索的过程中遇到一个多行字符串，则源代码分析器208将字符串读取至分号处，该分号被解释为字符串末尾。在代码审阅过程中解决所有其他的边界问题，因此在同一标准内实现了本地化样式的创建机制。根据一个示例性实施例，在形成本地化样式列表之后，自动添加本地化标记。在形成本地化样式列表之后，源代码分析器208使用保存的本地化样式在具有特定文件扩展名(例如，js)的所有文件中查找条目。例如，如果有一个样本label:标记，那么找到该行的末尾，该末尾处有样本字符串标记(例如双引号)，然后如果样本字符串标记不存在，则使用本地化标记扩展该字符串。例如：label:"teststring"--->label:_("teststring")然后，通过apsmsgmake工具实现行传播过程(其中具有本地化标记的所有代码行被移动到po文件)，如图2所示。在步骤204，apsmsgmake有助于将放置在引号内的内容放置在消息文件(*.po)内，并且这成为本地化密钥。在将所有本地化密钥添加到当地地区的.po消息文件(例如“en_us.po”)之后，在210中开始区域设置分析。区域设置分析器为所有现有的msgld’s解析当地语言*po消息文件。之后，该工具会比较本土语言文件和其他语言文件，并使用其他语言文件未显示的msgld’s扩展其他语言文件。然后，使用配置用于处理gettext文件(*.po)(框214)的任何可用库来启动行国际化过程(框212)。应当理解，gettext文件基于通常用于编写多语言程序的国际化兼本地化(il8n)系统。例如，对于python编程语言，可以使用“polib”库。googletranslateapi可用于行的自动翻译。对于每个msgid(*po文件中的字符串由密钥组成)，翻译引擎(例如使用json格式的googletranslateapi的googletranslate)发送翻译请求，这里举出了一个非限制性示例。如果该翻译请求成功执行，则服务器将返回“ok”响应和json格式的翻译结果：根据示例性实施例，请求对aps应用程序支持的所有语言进行翻译，或请求仅对于具有系统中存在的.po消息文件的语言进行翻译。翻译选择是基于国际化脚本启动模式进行的。翻译后的行也以下列格式写入数据库(即数据库656)：根据示例性实施例，将适当的翻译行写入适当的gettext文件中。然后启动译文验证手动过程218。对其责任的技术撰码人检查自动翻译的字符串。在步骤220，在安装aps应用程序(即aps包222)之后，将消息文件(*.po)的内容转换为本地化文件*.json。根据示例性实施例，在.po消息文件和json之间对代码行进行验证(框224)。在安装软件包后，验证脚本会从.po消息文件中导入所有本地化密钥和相应的本地化值。然后，脚本检查具有相同名称和文件扩展名*.json的文件。随后，脚本将加载到内存中的密钥和值与json文件中的密钥和值进行比较。如果未找到密钥或值，则创建自动错误报告(框226)，并且可以将其发送给应用程序开发者，这里举出了一个非限制性示例。现在参照图3，根据本公开的一个实施例，示出了的用于检查以本地化样本填充数据库的源代码中的非本地化行的方法的流程图。在步骤305中，如上所述，由apsmsgmake工具生成.po消息文件。在本公开的至少一个实施例中，apsmsgmake命令将翻译字符串提取到.po消息文件中，每种语言一个文件。此文件是翻译器以目标语言提供翻译字符串的译文的一种便捷方式。apsmsgmake实用程序使用特殊的陷阱(即钩子)以从用于安装gui的aps命令行工具的集合中导出本地化数据。在步骤310中，解析当地地区.po消息文件。例如，en_us.po是针对美国(us)英语语言(en)的地区.po消息文件。.po消息文件名为ll_cc.po的形式。双字母原代码(ll)由iso639-1语言规范进行定义。双字母子代码(cc)根据iso3166-1国家规范进行解释。语言部分总是用小写字母写成，而国家部分用大写字母书写。分隔符是下划线(“_”)。在本公开的至少一个实施例中，.po消息文件是纯文本文件，表示包含了所有可用的翻译字符串的单一语言及这些字符串在给定语言下的解释(译文)。可以理解，.po消息文件可以由许多条目组成，每个条目描述原始未翻译字符串与其对应译文之间的关系：msgid“[这里是原始翻译字符串]”msgstr“[这里是翻译后的字符串]”在步骤320，该过程确定了字符串msgid是否已经存在于数据库(例如，数据库656)中。如果存在msgid，则该过程返回到步骤310。否则，该过程在步骤330中收集本地化样式。然后，该过程在步骤340中将本地化样式保存到数据库656中，并将报告212发送给责任方(例如技术撰码人)。应当理解，报告212包含新添加的、能由开发者或技术撰码人分析的本地化样式，以便将其排除并且破例地不将这样的字符串识别为本地化样式。在步骤350中，该过程确定了它是否已到达.po消息文件的文件结尾(eof)。如果已到达eof，则该过程在步骤360结束。否则，该过程返回到步骤310。现在参照图4，根据本公开的一个实施例，示出了用于使用本地化样本填充数据库的源代码中的行的自动国际化的方法的流程图。在步骤405中，如上所述，由apsmsgmake工具生成.po消息文件。在至少一个实施例中，可以在源代码分析器的工作之后从前一阶段检索*po文件(步骤204的第二次迭代)。在本公开的至少一个实施例中，apsmsgmake命令将翻译字符串提取到.po消息文件中，每种语言一个文件。此文件是翻译器以目标语言提供翻译字符串的译文的一种便捷方式。apsmsgmake实用程序使用特殊陷阱(即，钩子)以便从用于安装gui的aps命令行工具的集合中导出本地化数据。在本公开的至少一个实施例中，该过程为需要翻译的每个地区自动创建多个.po消息文件。将进一步理解的是，针对每个地区的.po消息文件包括需要翻译的每个msgid。在步骤410中，如步骤310中所公开的，解析本土地区.po消息文件。在步骤415中，如果另外的地区存在msgid，则该过程在步骤430中经由网络658通过请求将msgid发送到翻译引擎(例如googletranslateapi)，并接收翻译后的字符串。否则，该过程通过msgid扩展另外的地区420(即如果需要，该过程会将msgid添加到另外的地区)，并转到步骤410。然后，在步骤440中，该过程将翻译后的字符串保存到消息文件中，该消息文件被提供给每个另外的地区并进入数据库(例如数据库656)，并且发送报告。在步骤450中，该过程检查其是否已到达.po消息文件的文件结尾(eof)。如果已到达eof，则该过程在步骤460结束。否则，该过程返回到步骤410。现在参照图5，根据示例性实施例，示出了用于验证.po消息文件与json之间的行的过程的流程图。在步骤505中，该过程针对当地地区从.po消息文件中获取msgid。在步骤510中，该过程针对所有现存的地区来解析地区参考文件(即jsonil8n文件)。在步骤520中，该过程确定：除了默认值为空(emty)的当地地区之外，.po消息文件中的密钥/值是否等于地区参考文件(即jsonil8n文件)。因此，对于当地地区而言，仅比较密钥的值。如果.po消息文件中的密钥/值等于地区参考文件，则该过程在步骤530确定json(地区参考文件)文件是否已到达文件结尾(eof)。如果json文件已到达文件末尾(eof)，则该过程在步骤560结束。否则，该过程移至步骤510。在步骤520中，如果.po消息文件中的密钥/值不等于地区参考文件，则该过程在步骤540中将缺少的字符串保存到数据库656中并且向责任方(例如负有责任的技术撰码人)发送报告，并且进入步骤510。在步骤550中，手动处理错误。参考图6，示出了用于自动检测、校正和翻译非本地化的代码行的系统和部件，通常为650。根据执行在计算机或计算机网络上的程序、数据结构或规程来呈现该描述。由系统实现的软件程序可以用任何编程语言编写——解释、编译或以其他方式。这些语言可以包括但不限于php、asp.net、html、html5、ruby、perl、java、python、c++、c#、javascript和/或go编程语言。当然，应当理解，本领域技术人员将理解，可以替代地或者与前述结合地使用其他语言，并且也可以使用web和/或移动应用程序框架，例如，例如，rubyonrails、node.js、zend、symfony、revel、django、struts、spring、play、jo、twitterbootstrap及其它。还应当理解，本文公开的系统和方法可以体现在计算机网络(例如因特网)上可用的软件即服务(software-as-a-service)中。此外，本公开可以通过一个或多个应用程序编程接口或其他方式实现web服务、应用程序编程接口和/或面向服务的体系结构。图6示出了用于对非本地化的代码行进行自动检测、校正和翻译的系统。在本公开的至少一个实施例中，该系统包括用户gui652、服务器654、数据库656和计算机网络658。用户gui652可以被配置为在计算机网络658上向web服务和/或服务器654上容纳的应用程序编程接口基础设施发送信息并且与之进行一般性交互。用户gui652可以包括web浏览器、移动应用程序、端口号(socket)或隧道或其他网络连接软件，以使得可以经由计算机网络658与服务器654上的web服务基础结构进行通信。用户gui652包括一个或多个计算机、智能手机、平板电脑、可穿戴技术、计算设备或本领域公知类型的系统，例如大型计算机、工作站、个人计算机、膝上型计算机、手持计算机、移动电话、mps播放器或个人数字助理。用户gui652包括本领域技术人员将想到的此类软件、硬件和组件，例如，一个或多个微处理器、存储器系统、输入/输出设备、设备控制器等。用户gui652还包括一个或多个数据输入装置(图6中未示出)，其可由用户gui652的客户操作以用于数据输入，例如语音或音频控制、指点设备(诸如鼠标)、键盘、触摸屏、麦克风、语音识别和/或本领域已知的其他数据输入装置。用户gui652还包括显示装置，该显示装置可包括各种类型的已知显示器，例如液晶二极管显示器、发光二极管显示器等，在显示器上可以以顾客可感知的方式显示信息。应当理解，根据本公开，用户gui652可以进一步包括如本领域技术人员将想到的软件、硬件和元件，以便可操作地执行分配给用户gui652的功能。数据库656被配置为存储由系统生成和/或从一个或多个信息源检索的信息。在本公开的至少一个实施例中，数据库656可以与服务器654以如下这种方式“关联”：其中数据库656驻留在服务器654上。数据库656还可以与服务器654以如下这样的方式“关联”：其中数据库656驻留在远离服务器654的服务器或计算设备上，前提是远程服务器或计算设备能够在例如amazonaws、rackspace或其他虚拟基础架构或任何业务网络中与服务器654进行双向数据传输。在本公开的至少一个实施例中，数据库656所驻留的远程服务器或计算设备与服务器654电连接，使得远程服务器或计算设备能够与服务器654进行连续的双向数据传输。为清楚起见，图6中示出了数据库656，并在这里称为单个数据库。本领域普通技术人员将理解，数据库656可以包括由本领域公知类型的软件系统连接的多个数据库，这些软件系统可共同操作以执行根据本发明委派给数据库656的功能。数据库656还可以是分布式数据架构的一部分，例如，用于大数据服务的hadoop架构。数据库656可以包括相关的数据库体系结构，nosql、olap或数据库领域中已知类型的其他数据库体系结构。数据库656可以包括许多众所周知的数据库管理系统之一，例如，microsoft的sqlserver、microsoft的access、mongodb、redis、hadoop或ibm的db2数据库管理系统，或oracle或sybase提供的数据库管理系统。数据库656可检索地存储从用户gui652或服务器654向数据库656通信的信息。已经如此描述了实施例，对于本领域技术人员来说显而易见的是，已经实现了所描述的方法和系统的某些优点。还应当理解，可以在本公开的范围和精神内进行各种修改、改编和替代实施例。通过所附权利要求进一步限定本公开。当前第1页12